Metasploit para Pentesters en los RootedLabs

Como ya sabréis todos, los días 3, 4 y 5 de Marzo de 2011 tiene lugar en Madrid las Conferencias RootedCON, que iniciaron su andadura el año pasado con gran éxito.

Como parte de las conferencias, unos días antes, los días 28 de Febrero, 1 y 2 de Marzo, tienen lugar los RootedLabs, una serie de cursos de formación de todo tipo de una jornada de duración a un precio de 200€+IVA cada uno de ellos.

Uno de ellos, con el título "Metasploit para Pentesters" será impartido por mi mismo, y a lo largo del curso aprenderemos a manejar la Metasploit, a lanzar exploits de diferentes tipos, utilizar diferentes payloads, y todo lo necesario para utilizar Metasploit dentro de un Test de Intrusión.

¡Apuntate ya!

Por supuesto, hay muchos más cursos muy interesantes dentro de los RootedLabs, de una temática muy diversa, así que te recomiendo que le pegues un vistazo a la lista y elijas el que más se adapta a tus necesidades o gustos:

• Alejandro Ramos - Test de intrusión
• Chema Alonso - Open Source Intelligence Gathering for Pentesting with FOCA
• Chema Alonso - Técnicas de Inyección en aplicaciones web
• José Selvi - Metasploit para Pentesters
• Joxean Koret - Fundamentos de Ingeniería Inversa
• Juan Garrido - Análisis Forense de red
• Juan Luis G. Rambla - Ataques en redes de datos
• Pedro Sánchez - Análisis Forense de Dispositivos Móviles

Para más información, acudid directamente a la web de los RootedLabs:

http://www.rootedcon.es/rootedlabs/rootedlabs-2011.html

SQLMap, SQL Server & Hyphens

Hace algún tiempo me encontré con una situación interesante mientras auditaba una aplicación web conectada a un servidor de base de datos Microsoft SQL Server que provocaba que ninguna de las herramientas que utilizo habitualmente para la explotación de Blind SQL Injection funcionara correctamente.

La aplicación web presentaba una vulnerabilidad de Inyección SQL en uno de sus parámetros. Evidentemente no puedo mostrar la aplicación real que contenía el fallo, pero pongamos que la aplicación tenía un código como el siguiente:

Evidentemente, la aplicación es vulnerable a Inyección SQL, y ni siquiera Inyección SQL Ciega, pero vamos a usarlo como ejemplo.

Si lanzamos la herramienta SQLMap para la detección y explotación del parámetro "id", obtenemos lo siguiente:

# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id

Perfecto! SQLMap detecta correctamente que el parámetro "id" es vulnerable, y nos muestra el fingerprint del servidor de base de datos. Ahora, como un posible segundo paso, veríamos las bases de datos contenidas en el servidor:

# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id --dbs

Cuando llegué a este punto en la auditoría, intenté ir accediendo a la información contenida en las bases de datos, pero cuando le tocó a "test-db" me encontré con algo así:

# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id -D "test-db" --tables

Parece que por algún motivo no puedo recuperar las tablas de la base de datos. No hubo manera de hacerlo funciona cambiando las opciones, ni tampoco era por un tema de permisos, puesto que era la base de datos utilizada por la aplicación web. Probé otras herramientas y nada, todas me devolvían el mismo resultado.

Al final, lancé SQLMap con la opción "-v 2", para así poder ver con algo más de detalle que estaba pasando, y obtuve lo siguiente:

# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id -D "test-db" --tables -v 2

La SQL, a mis ojos, parecía correcta, pero por si acaso me la llevé a una maqueta de Microsoft SQL Server y la lancé, con lo que obtuve un "bonito" error de sintaxis:

"Sintaxis incorrecta cerca de -", y el único "-" que hay en la SQL es el del nombre de la base de datos, así que... no puede ser que el guión (hyphen) sea un carácter no permitido para nombres de tablas en Microsoft SQL Server, porque de hecho la tabla existe, pero parece tratarse de algún tipo de carácter especial en SQL que deberá ser escapado de alguna manera.

Revisando la documentación del SQL Server y referencias varias en Internet, me encontré con que es posible definir el nombre de una tabla entre corchetes, y que eso podría evitar que ese guión fuera interpretado como lenguaje SQL. Veamos que pasa si cambiamos la SQL anterior incluyendo esos corchetes:

Bueno, parece que SÍ que era ese el problema, así que solo necesitamos decirle a SQLMap que el nombre de nuestra base de datos es "[test-db]" en lugar de "test-db" para poder seguir extrayendo la información.

Tras extraer el nombre de las tablas (opción --tables), vemos una llamada "usuarios", así que aprovechamos lo que acabamos de aprender para obtener todo el contenido de la tabla:

# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id -D "[test-db]" -T usuarios --dump

Hay otra manera de corregir este problema para que no nos vuelva a suceder ni ahora ni nunca, independientemente del nombre que tengan las bases de datos. SQLMap contiene las sentencias SQL dentro de un fichero llamado queries.xml (en el directorio "xml" del sqlmap), con lo que podemos realizar pequeñas (o grandes si nos atrevemos) modificaciones sobre ellas, entre las cuales podemos incluir corchetes en las referencias a nombre de tablas, que serán del tipo %s..loquesea, y que tras la modificación pasarán a ser [%s]..loquesea, o de tipo [DB]..loquesea que pasará a ser [[DB]]..loquesea, solo para la zona de sentencias para SQL Server, por supuesto:

Una vez hecho esto podemos lanzar la herramienta de una forma totalmente normal, y no volveremos a encontrarnos este problema.

Cualquiera de las dos formas nos vale para solucionar nuestro problemilla, aunque a mi me gusta más la segunda. No será la primera vez que toca modificar algo en el código de sqlmap para adaptarlo alguna situación concreta, como por ejemplo WAFs que filtran algunas palabras y que fastidian un poco.

Pero eso ya para otro post.

Pregunta de la No cON Name

Durante la charla que dimos en la No cON Name sobre "IP Fragmentation Overlapping", en la ronda de preguntas, uno de los asistentes preguntó si era posible encontrar overlapping en un tráfico normal de la red, es decir, sin que existan malas intenciones.

Yo respondí que, desde mi punto de vista, NO, ya que el overlapping es una situación completamente anómala, y ninguna pila TCP/IP debería fragmentar con overlapping, así que si nos encontramos una fragmentación con overlapping, casi 100% seguro tenemos detrás alguna persona con no muy buenas intenciones.

Tras mi respuesta, una persona levantó la mano y me planteo una situación, que era... ¿qué pasa si los fragmentos van por un camino muy lento, tanto que salta el timeout del origen y vuelve a reenviar los datos, y esta vez van por otro camino más rápido, de tal forma que llegan al destino ambos fragmentos a la vez? Entonces se produciría overlapping sin que sea un ataque, ¿no?

Mi respuesta estuvo basada completamente en la suposición y en el conocimiento que tengo de como funciona la fragmentación ip y las redes en general, pero tal y como dije en las conferencias, es algo que no podía garantizarles sin probarlo.

Ahora, después de probarlo, vamos a darle una respuesta algo más que teórica a esta pregunta:

1. En caso de que se produjeran, los dos fragmentos con el mismo offset deberían tener EXACTAMENTE los mismos datos, así que el método de defragmentación sería indiferente. Si algo similar a esto ocurriera, la clave para determinar si es un ataque o alguna anomalía en la red, es comprobar el contenido de los fragmentos. Si los fragmentos que hacen overlapping tienen exactamente el mismo contenido, no hay problema, no se trata de un ataque. Si tienen contenido diferente... alerta! alguien ahí fuera está intentando algo.
2. Mi respuesta, basada en la lógica, es que dado que no se recibe un ACK de cada fragmento, sino que se recibe el ACK del paquete una vez defragmentado, en caso de no recibirse el ACK (por congestión, porque se pierde un fragmento y no se puede reconstruir, porque el checksum del paquete defragmentado ha fallado, por lo que sea), el origen vuelve a enviar el paquete (al no recibir ACK), y este paquete (que no fragmento) viajará por la red, y si llega a un router en el que debe ser fragmentado, se fragmentará, pero es posible que ni siquiera sea el mismo router que realizó la anterior defragmentación, así que el IPID sería diferente.

No dispongo de una infraestructura de red como para probar todo esto, pero haciendo una pequeña prueba con fragroute con una configuración como la de la segunda demo de las conferencias, ya que en ocasiones (como se puede ver en la demo) no se fragmentaba correctamente y la conexión no funcionaba. En estos casos, he realizado una captura de red para observar los IPID de los fragmentos al ser reenviados, y este ha sido el resultado:

Como podéis ver, el Linux asigna IPIDs consecutivos para cada fragmentación, y aunque evidentemente esto es algo que puede cambiar con el tipo de pila TCP/IP del sistema que realiza la fragmentación, entendemos que es más que improbable que dos paquetes con mismo origen, destino, número de secuencia, etc, resultaran ser fragmentados con el mismo IPID (sería una sucesión de colisiones muy complicada).

Aún así, la posibilidad teórica existe, y en ese caso, como decíamos anteriormente, el contenido es el que nos dirá si se trata de un ataque o no.