Protección contra las técnicas de Blind SQL Injection (II de IV)

***************************************************************************************
Protección contra las técnicas de Blind SQL Injection (I de IV)
Protección contra las técnicas de Blind SQL Injection (II de IV)
Protección contra las técnicas de Blind SQL Injection (III de IV)
Protección contra las técnicas de Blind SQL Injection (IV de IV)
***************************************************************************************
Automatización

A partir de esta teoría, en las conferencias de BlackHat USA de 2004, Cameron Hotchkies, presentó un trabajo sobre “Blind SQL Injection Automation Techniques” en el que proponía métodos de automatizar la explotación de un parámetro vulnerable a técnicas de Blind SQL Injection mediante herramientas. Para ello no parte de asumir que todos los errores puedan ser procesados y siempre se obtenga un mensaje de error, ya que la aplicación puede que tenga un mal funcionamiento y simplemente haya cambios en los resultados. En su propuesta, ofrece un estudio sobre realizar inyecciones de código SQL y estudiar las respuestas ante ISQL0 e ISQL+.

Imagen: Presentación en Blackhat USA 2004
Propone utilizar diferentes analizadores de resultados positivos y falsos en la inyección de código para poder automatizar una herramienta. El objetivo es introducir ISQL0 e ISQL+ y comprobar si los resultados obtenidos se pueden diferenciar de forma automática o no y cómo hacerlo.

1.- Búsqueda de palabras clave: Este tipo de automatización sería posible siempre que los resultados positivos y negativos, fueran siempre los mismos. Es decir, siempre el mismo resultado positivo y siempre el mismo resultado negativo. Bastaría entonces con seleccionar una palabra clave que apareciera en el conjunto de resultados positivos y/o en el conjunto de resultados negativos. Se lanzaría la petición con la inyección de código y se examinarían los resultados hasta obtener la palabra clave. Es de los más rápidos a implementar, pero exige cierta interacción del usuario que debe seleccionar correctamente cual es la palabra clave en los resultados positivos o negativos.

2.- Basados en firmas MD5: Este tipo de automatización sería valido para aplicaciones en las que existiera una respuesta positiva consistente, es decir, que siempre se obtuviera la misma respuesta ante el mismo valor correcto (con inyecciones de código de cambio de comportamiento cero) y en el caso de respuesta negativa (ante inyecciones de cambio de comportamiento positivo), se obtuviera cualquier resultado distinto del anterior, como por ejemplo, otra página de resultados, una página de error genérico, la misma página de resultados pero con errores de procesamiento, etc… La automatización de herramientas basadas en esta técnica es sencilla:

a.- Se realiza el hash MD5 de la página de resultados positivos con inyección de código de cambio de comportamiento cero. Por ejemplo: “and 1=1”.

b.- Se vuelve a repetir el proceso con una nueva inyección de código de cambio de comportamiento cero. Por ejemplo: “and 2=2”.

c.- Se comparan los hashes obtenidos en los pasos a y b para comprobar que la respuesta positiva es consistente.

d.- Se realiza el hash MD5 de la página de resultados negativos con inyección de código de cambio de comportamiento positivo. Por ejemplo “and 1=2”.

e.- Se comprueba que los resultados de los hashes MD5 de los resultados positivos y negativos son distintos.

f.- Si se cumple, entonces se puede automatizar la extracción de información por medio de Hashes MD5.

Excepciones: Esta técnica de automatización no sería valida para aplicaciones que cambian constantemente la estructura de resultados, por ejemplo aquellas que tengan publicidad dinámica ni para aquellas en las que ante un error en el procesamiento devuelvan el control a la página actual. No obstante sigue siendo la opción más rápida en la automatización de herramientas de Blind SQL Injection.

3.- Motor de diferencia Textual: En este caso se utilizaría como elemento de decisión entre un valor positivo o falso la diferencia en palabras textuales. La idea es obtener el conjunto de palabras de la página de resultados positivos y la página de resultados negativos. Después se hace una inyección de código con un valor concreto y se obtiene un resultado de palabras. Haciendo un cálculo de distancias se vería de cual difiere menos para saber si el resultado es positivo o negativo. Esto es útil cuando el conjunto de valores inyectados siempre tengan un resultado visible en el conjunto de resultados tanto en el valor positivo como en el valor negativo.

4.- Basados en árboles HTML: Otra posibilidad a la hora de analizar si el resultado obtenido es positivo o negativo sería utilizar el árbol html de la página. Esto funcionaría en entornos en los que la página de resultados correctos y la página de resultados falsos fuera siempre distinta, es decir, la página correcto tiene partes dinámicas cambiantes ante el mismo valor y la página de errores también. En esos casos se puede analizar la estructura del árbol de etiquetas HTML de las páginas y compararlos.

5.- Representación Linear de Sumas ASCII: La idea de esta técnica es obtener un valor hash del conjunto de resultados en base a los valores ASCII de los caracteres que conforman la respuesta. Se saca el valor del resultado positivo, el resultado negativo. Este sistema funciona asociado a una serie de filtros de tolerancia y adaptación para poder automatizarse.

Junto con la presentación presentó una herramienta que implementaba el método 4 y que se llamaba SQueal. Dicha herramienta evolucionó hacia la que hoy se conoce como Absinthe.

Absinthe

Utiliza el mismo sistema que explicó en el documento “Blind SQL Injection Atomation Techniques” basado en sumas de valores. La herramienta es Software Libre y está programada en C# .NET, pero con soporte para MAC y para Linux con MONO. Es una de las más completas, con un interfaz muy cuidado y con soporte para la mayoría de las situaciones: Intranets con autenticación, conexiones SSL, uso de cookies, parámetros en formularios, necesidad de completar URLs, etc…

Hay que destacar que esta herramienta está pensada para auditores, y no detecta parámetros vulnerables, así que debe ser configurada de forma correcta. No es un wizard que se lanza contra una URL y ya te devuelve toda la estructura.

La herramienta funciona con plugins para diversas bases de datos y a día de hoy tiene soporte para Microsoft SQL Server, MSDE (desktop Edition), Oracle y Postgres. Los autores de la misma son Nummish y Xeron y tanto su código fuente como la herramienta están disponibles en la siguiente URL: Absinthe

Imagen: Configurando el servidor vulnerable.
En la herramienta hay que configurar el tipo de base de datos, la URL, el parámetro vulnerable, el tipo de método utilizado, etc… Una vez configurado correctamente la herramienta procede a bajarse el esquema de la base de datos utilizando la automatización descrita. Como se puede ver, la herramienta saca los tipos de datos. Para ello realiza consultas a las tablas del esquema sysobjects, syscolumns, etc… Por último extrae los datos de las tablas. En los proximos artículos veremos un ejemplo de su funcionamiento.

Como se puede suponer este no es un proceso especialmente rápido, pero… ¿qué más da si saca toda la información?

No es esta la única herramienta de automatización que existe hoy en día en la automatización de blind SQL Injection, pero tampoco quiero citarlas todas (aunque no son demasiadas y se podría), así que citaré algunas con diversas técnicas de automatización.

¿Y que más?

Personalmente espero que estos primeros artículos hayan causado en vosotros el efecto de preocuparos y comencéis un proceso de auditoría contra Blind SQL Injection y que el mes que viene vengáis a leer otra vez como acaba este serie de artículos. ¿Quieres probar el Blind SQL Injection? Puedes hacerlo con el Primer Reto Hacking de El lado del Mal que es un Blind SQL Injection. Y si no te sale, aquí tienes el solucionario.