jueves, 25 de septiembre de 2008

Marathon Tool & Heavy Querys

Otra herramienta de las utilizadas en la DEFCON de este año es Marathon Tool, una herramienta para auditoría web basada en inyecciones de código SQL "pesado".

La inyección SQL, como todos sabemos, es una vulnerabilidad causada por una mala comprobación de los parámetros de entrada que finalmente se traducen en una solicitud SQL a base de datos diferente de la que la aplicación web está pensada para hacer.

Generalmente, si escogemos una página web aleatoriamente en todo Internet, buscamos un campo formulario y escribimos una comilla simple (') nos encontraremos algo como esto:


Encontrarnos un error de la base de datos o incluso una sentencia SQL completa como en este caso es un claro signo de que el campo formulario que hemos encontrado sufre de una vulnerabilidad de Inyección SQL.

Este es el caso más fácil, que nos muestre claramente la web algo como esto, pero no siempre esto es posible, en ocasiones está filtrada este tipo de salida, o simplemente la salida de la sentencia SQL no es utilizada para mostrar ningún contenido en la web, por lo que para detectar si la web es vulnerable o no y para intentar explotarlo tendremos que recurrir a un Blind SQL Injection, que como su propio nombre indican son "ciegas", o mejor dicho "no evidentes", puesto que obtenemos igualmente información aunque sea por otros medios.

De entre todas las técnicas de Blind SQL Injection que existen, la herramienta Marathon Tool utiliza una técnica basada en querys SQL pesadas, ¿que quiere decir esto exactamente?, pues bien, imaginaros que una aplicación SQL normal tiene una query que es ejecutada y ofrece una respuesta en un tiempo de X segundos, tiempo que podemos apreciar más o menos observando la respuesta de la página (en función también un poco de la latencia de la red, claro). ¿Que pasa si intentamos inyectar un código que en caso de funcionar correctamente realice una consulta sin ninguna intención específica de obtener información pero que sabemos que va a tener un coste para la base de datos de 1000X segundos?. Pues en el caso de que no funcione el tiempo de carga de la web será el habitual, mientras que si funciona observaremos que el tiempo de carga es muy superior al habitual.

A partir de ahí, podemos usar esta Query para ir "haciendo preguntas" a la base de datos que tengan como respuesta sí o no y comprobando mediante ese timing cual es la respuesta que nos da la base de datos, y así de esta manera ir obteniendo información de tablas, contenidos de tablas (usuarios y contraseñas) y un largo etcetera.

Sin duda alguna, menos cómodo que obtener el listado de usuarios y passwords mostrados directamente en el contenido de la web, pero igualmente factible con un poco más de trabajo.

Aquí es donde entra esta herramienta tan interesante, tras ser configurada adecuadamente permite automátizar el proceso de búsqueda de tablas y usuarios de tal manera que no tenemos que ir realizando esas preguntas que comentabamos de forma manual, sino que es la herramienta la encargada de realizar cuantas consultas sean necesarias e ir obteniendo esta información.


Una gran herramienta, sin duda.

No hay comentarios :