SQL Injection, ese “viejo amigo”
No llevan tantos años entre nosotros las técnicas de SQL Injection para atacar a aplicaciones web y parece que lleven toda la vida. En esto de la tecnología siempre sucede esto, parece que llevo utilizando servidores Windows 2003 de siempre y resulta que no llevo tanto y [chiste malo] si te paras a pensar resulta que en Barcelona 92, en las olimpiadas, aún no había salido Windows 95 [/chiste malo].
Con las técnicas de SQL Injection sucede algo similar, fue rain.forest.puppy en el Phrack Magazine Volumen 8, Número 54 del 25 de Diciembre de 1998, una publicación realizada por la comunidad y para la comunidad de Internet, quién publicó un artículo titulado “NT Web Technology Vulnerabilities” en el que analizaba las posibilidades de la inyección de código SQL en aplicaciones ASP y motores de bases de datos SQL Server 6.5 aunque en ese momento no se llamaba SQL Injection, el le llamaba algo así como “añadir consultas”. Poco después hackearía la web PacketStorm utilizando estas técnicas, y lo explicaría en un documento que se llamaba “How i Hacked PacketStorm”. No se llamaría aún SQL Injection, es más, el nombre de SQL Injection no lo recibiría hasta el día 23 de Octubre de 2003 en la web SQLSecurity.com, Chip Andrews, publicara “SQL Injection FAQ”.
A partir de ese momento las posibilidades han sido estudiadas en profundidad en diferentes artículos y manuales disponibles en la web. Dignos de citar esos documentos, si quieres realmente saber como pueden afectar a cualquier aplicación web son recomendables los siguientes:
La primera buena discusión sobre los riesgos de diseñar aplicaciones sin protección contra SQL Injection la escribió David Litchfield de NGS Softweare, en el año 2001 con el nombre de “Web Application Disassembly with ODBC Error Messages”.
“Advanced SQL Injection en Microsoft SQL Server”, publicado el año 2002 por Chrish Anley de NGS Software y la segunda, y aún mejor parte “(more) Advanced SQL Injection” del mismo autor y publicada en Junio del mismo año.
Digno de citar es también el estudio de Cesar Cerrudo, de la empresa Application Security, que fue publicado en el mes de Agosto de 2002 y con el título “Manipulating Microsoft SQL Server using SQL Injection”.
¿Puestos al día con SQL Injection? Pues vamos un poco más allá con ello.
Blind Sql Injection
Una de las formas de realizar estos ataques se basa en ataques a ciegas, es decir, en conseguir que los comandos se ejecuten sin la posibilidad de ver ninguno de los resultados. La inhabilitación de la muestra de los resultados del ataque se produce por el tratamiento total de los códigos de error y la imposibilidad de modificar, a priori, ninguna información de la base de datos. Luego, si no se puede alterar el contenido de la base de datos y no se puede ver el resultado de ningún dato extraído del almacén, ¿se puede decir que el atacante nunca conseguirá acceder a la información?
La respuesta correcta a esa pregunta, evidentemente, es no. A pesar de que un atacante no pueda ver los datos extraídos directamente de la base de datos sí que es más que probable que al cambiar los datos que se están enviando como parámetros se puedan realizar inferencias sobre ellos en función de los cambios que se obtienen. El objetivo del atacante es detectar esos cambios para poder inferir cual ha sido la información extraída en función de los resultados.
La forma más fácil de automatizar para un atacante esta técnica es usar u vector de ataque basado en lógica binaria, es decir, en Verdadero y Falso. Este es el vector de ataque que va a centrar todo el estudio del presente proyecto, las Técnicas de Inferencia Ciega basada en Inyección de Comandos SQL.
El parámetro vulnerable
El atacante debe encontrar en primer lugar una parte del código de la aplicación que no esté realizando una comprobación correcta de los parámetros de entrada a la aplicación que se están utilizando para componer las consultas a la base de datos. Hasta aquí, el funcionamiento es similar al resto de técnicas basadas en inyección de comandos SQL. Encontrar estos parámetros es a veces más complejo ya que, desde un punto de vista hacker de caja negra, nunca es posible garantizar que un parámetro no es vulnerable ya que tanto si lo es, como si no lo es, puede que nunca se aprecie ningún cambio en los resultados aparentes.
Hagamos una definición, definamos el concepto de “Inyección SQL de cambio de comportamiento cero” (ISQL0) como una cadena que se inyecta en una consulta SQL y no realiza ningún cambio en los resultados y definamos “Inyección SQL de cambio de comportamiento positivo” (ISQL+) como una cadena que sí provoca cambios.
Veamos unos ejemplos:
Supongamos una página de una aplicación web del tipo:
http://www.miweb.com/noticia.php?id=1
Hacemos la suposición inicial de que 1 es el valor del parámetro id y dicho parámetro va a ser utilizado en una consulta a la base de datos de la siguiente manera:
Select campos
From tablas
Where condiciones and id=1
Una inyección ISQL0 sería algo como lo siguiente:
http://www.miweb.com/noticia.php?id=1+1000-1000
http://www.miweb.com/noticia.php?id=1 and 1=1
http://www.miweb.com/noticia.php?id=1 or 1=2
En ninguno de los tres casos anteriores estamos realizando ningún cambio en los resultados obtenidos en la consulta. Aparentemente no.
Por el contrario, una ISQL+ sería algo como lo siguiente
http://www.miweb.com/noticia.php?id=1 and 1=2 (a estas las llamo ISQL- ¿está claro por qué?)
http://www.miweb.com/noticia.php?id=-1 or 1=1
http://www.miweb.com/noticia.php?id=1+1
En los tres casos anteriores estamos cambiando los resultados que debe optener la consulta. Si al procesar la página con el valor sin inyectar y con ISQL0 nos devuelve la misma página se podrá inferir que el parámetro está ejecutando los comandos, es decir, que se puede inyectar comandos SQL. Ahora bien, cuando ponemos una ISQL+ nos da siempre una página de error que no nos permite ver ningún dato. Bien, pues ese es el entorno perfecto para realizar la extracción de información de una base de datos con una aplicación vulnerable a Blind SQL Injection.
¿Cómo se atacan esas vulnerabilidades?
Al tener una pagina de “Verdadero” y otra página de “Falso” se puede crear toda la lógica binaria de las mismas.
En los ejemplos anteriores, supongamos que cuando ponemos como valor 1 en el parámetro id nos da una noticia con el títular “Raúl convertido en mito del madridismo”, por poner un ejemplo y que cuando ponemos 1 and 1=2 nos da una página con el mensaje Error. A partir de este momento se realizan inyecciones de comandos y se mira el resultado.
Supongamos que queremos saber si existe una determinada tabla en la base de datos:
Id= 1 and exists (select * from usuarios)
Si el resultado obtenido es la noticia con el titular de Raúl, entonces podremos inferir que la tabla sí existe, mientras que si obtenemos la página de error sabremos que o bien no existe o bien el usuario no tiene acceso a ella o bien no hemos escrito la inyección correcta SQL para el motor de base de datos que se está utilizando (Hemos de recordad que SQL a pesar de ser un “estándar” no tiene las mismas implementaciones en los mismos motores de bases de datos). Otro posible motivo de fallo puede ser simplemente que el programado tenga el parámetro entre paréntesis y haya que jugar con las inyecciones por ejemplo, supongamos que hay un parámetro detrás del valor de id en la consulta que realiza la aplicación. En ese caso habría que inyectar algo como:
Id= 1) and (exists (select * from usuarios)
Supongamos que deseamos sacar el nombre del usuario administrador de una base de datos MySQL:
Id= 1 and 300>ASCII(substring(user(),1,1))
Con esa inyección obtendremos si el valor ASCII de la primera letra del nombre del usuario será menor que 300 y por tanto podemos decir que esa es un ISQL0. Lógicamente deberemos obtener el valor cierto recibiendo la noticia de Raúl. Luego iríamos acotando el valor ASCII con una búsqueda dicotómica en función de si las inyecciones son ISQL0 o ISQL+.
Id= 1 and 100>ASCII(substring(user(),1,1)) -> ISQL+ -> Falso
Id= 1 and 120>ASCII(substring(user(),1,1)) -> ISQL0 ->Verdadero
Id= 1 and 110>ASCII(substring(user(),1,1)) -> ISQL+ ->Falso
Id= 1 and 115>ASCII(substring(user(),1,1)) -> ISQL0 ->Verdadero
Id= 1 and 114>ASCII(substring(user(),1,1)) -> ISQL+ ->Falso
Luego podríamos decir que el valor del primer character ASCII del nombre del usuario es el 114. Un ojo a la tabla ASCII y obtenemos la letra ‘r’, probablemente de root, pero para eso deberíamos sacar el segundo valor, así que inyectamos el siguiente valor:
Id= 1 and 300>ASCII(substring(user(),2,1)) -> ISQL0 -> Verdadero
Y vuelta a realizar la búsqueda dicotómica. ¿Hasta que longitud? Pues averigüémoslo inyectando:
Id= 1 and 10> length(user()) ¿ISQL0 o ISQL+?
Todas estas inyecciones, como se ha dicho en un parrafo anterior deben ajustarse a la consulta de la aplicación, tal vez sean necesiaros paréntesis, comillas si los valores son alfanuméricos, secuencias de escape si hay filtrado de comillas, o caracteres terminales de inicio de comentarios para invalidad partes finales de la consulta que lanza el programador.
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+.
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:
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.
En el artículo del mes pasado se explicó como mediante técnicas a ciegas es posible sacar información de una base de datos sin llegar a ver los resultados de las consultas. En el presente mes vamos a ver una serie de herramientas que podéis utilizar para analizar y para probar la seguridad de vuestras bases de datos. Muchas de ellas son gratuitas y de libre por lo que va a ser fácil que las probéis en vuestras aplicaciones.
SQLInjector
La primera herramienta que hay que conocer es ésta. A raíz de los estudios de David Litchfield y Chrish Anley, ambos de la empresa NGS Software, desarrollaron la herramienta SQLInjector. Esta herramienta utiliza como forma de automatización la búsqueda de palabras clave en los resultados positivos. Es decir, se busca encontrar una palabra que aparezca en los resultados positivos y que no aparezca en los resultados negativos.
Recordad que el objetivo de las técnicas de Blind SQL Injection es conseguir inyectar lógica binaria con consultas del tipo “y existe esta tabla” o “y el valor ASCII de la cuarta letra del nombre del administrador es menor que 100”. Siempre se busca realizar consultas que devuelvan verdad o mentira con lo que la aplicación al procesarlo devolvería la página original (que llamamos de verdad o cierta) o la página cambiada (que llamamos de mentira o falsa). Pero si no te acuerdas, te recomiendo releer el artículo del mes pasado dónde se explica en detenimiento.
Para probar si el parámetro es susceptible a Blind SQL Injection utiliza un sistema basado en inyecciones de código de cambio de comportamiento cero sumando y restando el mismo valor. Es decir, si tenemos un parámetro vulnerable que recibe el valor 100, el programa ejecuta la petición con 100 + valor – valor. Si el resultado es el mismo entonces el parámetro es susceptible a ataques de SQL Injection.
Como utiliza búsqueda de palabra clave en resultados positivos hay que ofrecerle la palabra clave manualmente, es decir hay que lanzar la consulta normal y ver que palabras devuelve el código HTML. Después tenemos que lanzar una consulta con algo que haga que sea falso, por ejemplo con AND 1=0 y ver que palabras aparecen en los resultados de Verdad y no aparecen en los falsos (con seleccionar una palabra valdría). El código fuente de esta aplicación está escrito en Lenguaje C, es público y se puede descargar de la web:
SQL Injector
Para ejecutarse se hace con un comando como el siguiente:
C:>sqlinjector -t www.ejemplo.com -p 80 -f request.txt -a query -o where -qf query.txt -gc 200 -ec 200 -k 152 -gt Science -s mssql
Donde:
- t : Es el servidor
- p : Es el puerto
- f : La aplicación vulnerable y el parámetro. En un fichero de texto.
- a : La acción a realizar
- o : fichero de salida
- qf : La consulta a ejecutar a ciegas. En un fichero de texto.
- gc : Código devuelto por el servidor cuando es un valor correcto
- ec : Código devuelto pro el servidor cuando se produce un error
- k : Valor de referencia correcto en el parámetro vulnerable
- gt : Palabra clave en resultado positivo
- s : Tipo de base de datos. La herramienta está preparada para MySQL, Oracle, Microsoft SQL Server, Informix, IBM DB2, Sybase y Access.
Ejemplo de fichero request.txt
GET /news.asp?ID=#!# HTTP/1.1
Host: www.ejemplo.com
Ejemplo de query.txt
select @@version
La aplicación anterior hay que nombrarla obligatoriamente cuando se habla de técnicas de Blind SQL Injection, pero hoy en día existen otras muchas alternativas. Una especialmente pensada para motores de MySQL es SQLbftools.
SQLbftools
Publicadas por “illo” en reversing.org en diciembre de 2005. Son un conjunto de herramientas escritas en lenguaje C destinadas a los ataques a ciegas en motores de bases de datos MySQL basadas en el sistema utilizado en SQLInjector de NGS Software. El autor ha abandonado la herramienta y a día de hoy es mantenida por la web http://www.unsec.net por “dab”.
Esta compuesta de tres aplicaciones:
- mysqlbf: Es la herramienta principal para la automatización de la técnica de BlindSQL. Para poder ejecutarla se debe contar con un servidor vulnerable en el que el parámetro esté al final de la url y la expresión no sea compleja.
Soporta códigos MySQL:
o version()
o user()
o now()
o sytem_user()
o ….
Su funcionamiento se realiza mediante el siguiente comando:
Mysqlbf “host” “comando” “palabraclave”
Donde:
o host es la URL con el servidor, el programa y el parámetro vulnerable.
o Comando es un comando a ejecutar de MySQL.
o Palabraclave es el valor que solo se encuentra en la página de resultado positivo.
En la siguiente imagen vemos como lanzamos la aplicación contra una base de datos vulnerable y podemos extraer el usuario de la conexión.
Como se puede ver el programa ha necesitado 230 peticiones para sacar 18 bytes. En la siguiente imagen se ve como extraer la versión de la base de datos:
- mysqlget: Es la herramienta pensada para descargar ficheros del servidor. Aprovechando las funciones a ciegas y los comandos del motor de base de datos se puede ir leyendo letra a letra cualquier fichero del servidor.
En la siguiente imagen se ve como se puede descargar el fichero /etc/password a partir de una vulnerabilidad Blind SQL Injection usando mysqlget:
- mysqlst: Esta herramienta se utiliza para volcar los datos de una tabla. Primero se consulta al diccionario de datos para extraer el número de campos, los nombres, los tipos de datos de cada campo y por último el volcado de las filas.
Tienes más info en Blind SQL Injection en MySQL
Bfsql
Evolución de SQLBfTools, cuando “illo” abandonó las herramientas SQLbfTools A. Ramos, actualmente trabajando en la empresa Española SIA, la migró al lenguaje Perl en poco más de 500 líneas. La herramienta sigue utilizando el sistema de palabra clave en valores positivos. La herramienta no pide la intervención del usuario para averiguar cual es la palabra clave, sino que realiza peticiones con inyecciones de cambio de comportamiento cero e inyecciones de cambio de comportamiento positivo. Recibe las respuestas, un archivo de respuesta para el valor correcto y otro archivo para el valor incorrecto y las compara línea a línea buscando la primera diferencia. A partir de ese momento realiza peticiones y mira a ver a que valor corresponde.
La herramienta es de código abierto y la última versión, de Julio de 2006, está disponible para todo el mundo en la siguiente URL: http://www.514.es
SQL PowerInjector
Esta herramienta está escrita en .NET por Francois Larouche y ha sido liberada en el año 2006. SQL PowerInjector utiliza técnicas de SQL Injection tradicionales basadas en mensajes de error y técnicas de Blind SQL Injection usando dos sistemas. Comparación de resultados completos, equivalente a realizar un HASH MD5 de la página de resultados o bien, para los motores de Microsoft SQL Server, y sólo para esos motores, también se puede realizar utilizando el sistema basado en tiempos con WAIT FOR (o time delay) descrito por Chrish Anley en “(more) Advanced SQL Injection”. Para los motores de Oracle utiliza también, desde Mayo de 2007 inyección basada en tiempos llamando a los procedimientos almacenados de Oracle DBMS_LOCK y utilizando las funciones de Benchmark para generar retados en MySQL. La herramienta no ayuda a buscar parámetros vulnerables y se maneja mediante un trabajado interfaz gráfico.
La herramienta está adaptada a MS SQL Server, Oracle, MySQL y Sybase, es de código abierto y está disponible para descarga en la siguiente URL: http://www.sqlpowerinjector.com/
Un ejemplo con Absinthe
Hablamos de esta herramienta el mes pasado, pero hoy vamos a hacer un ejemplo completo real. Para ello hemos buscado una url “controlada” en la que teníamos un parámetro id que recibía un valor numérico en este caso.
http://www.miwebserver.com/miprograma.asp?id=370
Hemos realizado una sencilla prueba de inyección con:
http://www.miwebserver.com/miprograma.asp?id=370 and 1=1
http://www.miwebserver.com/miprograma.asp?id=370 and 1=0
Con la primera inyección (and 1=1) hemos obtenido la misma página que sin inyección y con la segunda inyección (and 1=0) hemos obtenido una página diferente, con otros resultados. Suponemos, o sabemos, que es SQL Server, pero como las alternativas son pocas (MS SQL Server, Oracle, DB2, MySQL, etc…) podríamos incluso ir probando diferentes motores. Configuramos absinthe:
Paso 1:Configuración de la inyección a ciegas:
- Seleccionamos el motor de bases de datos. En este caso Microsoft SQL Server porque lo sé, pero si desconozco la versión puedo chequear el checkbutton de “Verify SQL Server Version”.
- En target URL ponemos la llamada al programa sin poner los parámetros, en este caso: www.miwebserver.com/miprograma.asp
- En el envío de parámetros seleccionamos por GET.
- En la parte de parámetros creamos un parámetro ID con valor por defecto 370 en el que marcaremos que es inyectable.
- Realizamos una prueba con Initialize Injection.
Paso 2: Una vez configurado esto, la herramienta ya funciona sola, pasando a la pestaña de “DB Schema” podremos, en primer lugar averiguar el usuario, en segundo lugar, si el usuario tiene acceso al diccionario de datos, descubrir la estructura de tablas de la base de datos y por último consultando también al diccionario, descubrir los campos y tipos de datos de cada una de las columnas de las tablas. Una carencia de esta herramienta es la no posibilidad de descubrir los objetos por fuerza bruta, pero es perfecta en los entornos en los que el usuario tiene acceso al diccionario de datos. En la imagen se puede ver el usuario descubierto y las tablas que están siendo descubiertas.
Paso 2: Descubrimiento de usuario y tablas de la aplicación.
Para realizar este descubrimiento la aplicación va a generar por debajo un gran número de peticiones que funcionan como hemos explicado en el capítulo del mes pasado. En la siguiente imagen se puede ver una porción de las llamadas para descubrir los campos de las tablas.
Como se puede apreciar en las peticiones, al parámetro vulnerable se le une con un AND una petición en la que se intenta ver si un determinado carácter es igual a un determinado valor ASCII. Como se ve se está consultando a syscolumns y se utilizan valores UNICODE para evitar el filtrado de comas o comillas.
Paso 3: Extracción de datos de tablas. Una vez descubierta la estructura completa de la base de datos el último paso a realizar es descargar la lista de datos de los campos, para ello, con seleccionar la tercera pestaña accederemos a la lista de los campos descubiertos y podremos descargarlos a un fichero XML.
Otras herramientas
El número de herramientas que realizan descubrimiento y explotación de vulnerabilidades Blind SQL Injection crece día a día, pero no me gustaría terminar el artículo sin citar algunas otras:
SQL Ninja, escrita en Perl y que realiza inyección basada en tiempos para motores Microsoft SQL Server (tienes la herramienta en la siguiente URL: http://sqlninja.sourceforge.net/ y más información en: Blind SQL Injection (III). SQL Ninja
SQLiBF
Herramienta publicada en el año 2006, desarrollada por DarkRaven, un consultor de seguridad afincado en Murcia, está pensada y adaptada para bases de datos genéricas, pero también para bases de datos específicas en las que realiza comprobaciones de inyección de comportamiento cero. A diferencia de otras realiza tests de comprobación para saber si un parámetro es vulnerable basados en número de líneas, número de palabras o palabra clave:
La herramienta tiene como curiosidad también la búsqueda de terminadores de expresiones con paréntesis para poder completar las inyecciones correctamente. La herramienta es Software Libre y está disponible en la siguiente URL:
WebInspect
Esta herramienta se comercializa por la empresa SPI Dynamics desde el año 2005 y está mantenida bajo los estudios de Kevin Spett. Al ser una herramienta comercial no se dispone del código y solo se conoce su funcionamiento en base a las especificaciones del producto y a como es descrita en el documento “Blind SQL Injection. Are you web applications vulnerable?”. Funciona utilizando comprobaciones de error basadas en firmas, pero no se sabe si la aplicación utiliza la automatización basada en palabras clave. Lo que no aparece descrito en ningún apartado de las características es la utilización de automatismos basados en tiempo. Esta herramienta es una herramienta de carácter general en cuanto a seguridad de aplicaciones y está pensada para buscar todo tipo de vulnerabilidades. La información de la herramienta está disponible en la siguiente URL: WebInspect
Acunetix Web Vulnerability Scanner
Acunnetix es una herramienta de la que ya hablamos hace dos meses como una buena alternativa para la auditoría de aplicaciones web de forma automática. En la versión 4 de la herramienta se añadieron módulos para la detección de vulnerabilidades Blind SQL Injection y Blind XPath Injection (de estas últimas podríamos hablar algún día por esta sección). Esta herramienta una muy buena alternativa para realizar la comprobación de la seguridad de tu aplicación web, incluso para vulnerabilidades a ciegas.
Protección contra Blind SQL Injection
Las protecciones para SQL Injection son las mismas que contra SQL Injection. Fácil ¿no? Como hacerlo, pues comprobando absolutamente todo. Hoy en día, en todos los documentos técnicos en los que se evalúa el desarrollo de aplicaciones seguras está disponible un amplio estudio sobre como desarrollar protegiendo los programas contra la inyección de código.
Michael Howard, uno de los padres del modelo SDL (Secure Development Lifecycle) utilizado por Microsoft en el desarrollo de sus últimas tecnologías y escritor del libro Writting Secure Code (2nd edition) dedica todo un tema a evitar la inyección de código y lo titula de forma muy personal:
“All Input Is Evil! Until proven otherwise”
Además, casi todos los fabricantes o responsables de lenguajes de programación de aplicaciones Web ofrecen “Mejores Prácticas” para el desarrollo seguro dando recomendaciones claras y concisas para evitar la inyección de código. Así que a comprobar todo.
Toda consulta que se vaya a lanzar contra la base de datos y cuyos parámetros vengan desde el usuario, no importa si en principio van a ser modificados o no por el usuario deben ser comprobados y realizar funciones de tratamiento para todos los casos posibles. Hay que prever que todos los parámetros pueden ser modificados y traer valores maliciosos. Se recomienda utilizar códigos que ejecuten consultas ya precompiladas para evitar que interactúe con los parámetros de los usuarios.
Así mismo, como se ha visto los atacantes intentan realizar ingeniera inversa y extraer información de las aplicaciones en base a los mensajes o tratamientos de error. Es importante que se controlen absolutamente todas las posibilidades que puedan generar error en cualquier procedimiento por parte del programador. Para cada acción de error se debe realizar un tratamiento seguro del mismo y evitar dar ninguna información útil a un posible atacante.
Es recomendable que los errores, tanto los errores de aplicación como los de servidor, se auditen pues puede representar un fallo en el funcionamiento normal del programa o un intento de ataque. Se puede afirmar que casi el 100 % de los atacantes a un sistema van a generar algún error en la aplicación.
Espero que les sirva