Técnicas Avanzadas en ataquesBlind SQL Injection (Parte I de III)

***************************************************************************************
Artículo publicado en PCWorld Noviembre 2007:
- Técnicas Avanzadas en ataques Blind SQL Injection (I de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (II de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (III de III)
***************************************************************************************

Durante los meses de Junio y Julio se publicaron en PCWorld unos artículos orientados a comprender las técnicas de ataques basado en inyecciones ciegas [Parte I, Parte II, Parte III y Parte IV], detectar las vulnerabilidades manualmente o mediante el uso de escáneres y mitigar el impacto de un ataque no detectable. Estas técnicas de ataque se han extendido mucho en los tiempos que corren y es común ver exploits publicados constantemente que hacen uso de estos ataques. Basta visitar los últimos exploits para aplicaciones web publicados en Milw0rm y comprobar cómo las técnicas más usadas son RFI (Remote File Inclusion) y SQL Injection (en todas su vertientes).

Este artículo, en tres partes, va a volver a versar sobre las técnicas de Blind SQL Injection, pero en dos variantes muy especiales, la primera consiste en realizar inyecciones que retrasen la respuesta del motor de base de datos y la vamos a ver, en primer lugar, analizando un exploit que publicaron en Junio.

Breve repaso a Blind SQL injection

Para los que no hayan leído los artículos dedicados Blind SQL Injection y para aquellos que necesiten refrescar la memoria vamos a describir brevemente el funcionamiento de la técnica de ataque. El entorno es una aplicación web que recibe datos desde el cliente. Estos datos se utilizan para construir una consulta a la base de datos para extraer información. El atacante inyecta comandos SQL porque la aplicación es vulnerable a SQL injection pero nunca puede acceder a los resultados que devuelve la consulta porque la aplicación no los imprime. Sin embargo se puede apreciar un comportamiento distinto ante consultas que devuelven datos y consultas que no devuelven datos. A partir de este comportamiento distinto se intenta inyectar lógica para extraer la información en base a valores True o False.

Un exploit Blind SQL Injection basado en tiempos

Lo mejor será verlo con un exploit en publicado en el mes de Julio. No es necesario ser un super programador para entender su funcionamiento, aunque sí vamos a ver un poco de código:

Imagen: Exploit publicado en Milw0rm para sacar hash de admin
Analicemos el código de este exploit para entenderlo bien. Para que sea más cómodo el análisis se han numerado las líneas y se han coloreado y resaltado las más significativas. El objetivo de este exploit es inyectar una cadena SQL que acceda a la tabla dónde se almacena la contraseña del administrador. En la línea 7, en color azul, se puede ver que la cadena que va a inyectar accede al campo admin_pw de la tabla se_games para obtener la contraseña. Sin embargo esta cadena no devuelve el valor del campo pues la aplicación web no va a mostrar ese resultado por pantalla nunca. ¿Cómo resuelve el problema el atacante? Pues como se puede ver en la línea 7. El exploit genera un retardo de unos 5 o 6 segundos llamando a la función Benchmark si y sólo si el valor ASCII del carácter de la contraseña que se encuentra en la posición $j es igual al valor $i, que va recorriendo todo el alfabeto ASCII.

Esto le permitirá al atacante averiguar cada uno de los caracteres que componen el hash de la contraseña del usuario administrador. De la línea 8 a la 15 se realiza la construcción del paquete que se va a enviar al servidor web y puede comprobarse en la línea 13 como la inyección se realiza en el campo USER AGENT del mismo.

Esto es bastante curioso, pero hay que recordar que cualquier dato que venga desde el cliente y que vaya a ser utilizado en una consulta a la base de datos es potencialmente peligroso. Esto nos indica, que por alguna razón el servidor web está guardando estadísticas de los clientes que navegan por el sitio web en una base de datos. En este caso esto es tan peligroso como para extraer la contraseña.

La medición del retardo se puede ver resaltada en color Rojo. En la línea 6 se toma el tiempo antes de lanzar el paquete, se envía en la línea 16 y en la 17 se toma el tiempo después de llegar la respuesta. Se calcula la diferencia de tiempo y si ésta es mayor de 7 segundos entonces se infiere que el valor ASCII del carácter de la contraseña que se encuentra en la posición $j es igual al valor $i. Una vez averiguado ese carácter el exploit continúa a por el valor de la siguiente posición.

Sí, es una herramienta de ataque, pero hay que reconocer que el funcionamiento del exploit es muy interesante. En este caso hemos visto como se puede realizar un ataque de Blind SQL Injection basado en tiempos generando retardos usando una función intensiva en cálculo de MySQL. Para cada motor de base de datos existen formas distintas de generar retardos de tiempo. En SQL Server el uso de la función waitfor, en Oracle usando la llamada a DBMS_Lock.Sleep() y en MySQL usando las funciones Benchmark, como en el exploit de ejemplo, o con la función sleep en las versiones 5.

Imagen: Medición de tiempos en SQL Server 2000 usando la función waitfor. Como 1 es igual a 1 la respuesta tarda 10 segundos. Comienza a las 09:52:21 y termina a las 09:52:31.
El método visto en la imagen, el de waitfor, es el que utiliza la herramienta SQL Ninja. Sin embargo, estas no son las únicas opciones para la generación de retardos de tiempo en ataques a ciegas.

***************************************************************************************
Artículo publicado en PCWorld Noviembre 2007:
- Técnicas Avanzadas en ataques Blind SQL Injection (I de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (II de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (III de III)
***************************************************************************************