05/08/12 by Alejandro Nolla | Uncategorized | No Comments »
pffdetect (http://code.google.com/p/pffdetect/)es un módulo desarrollado en Python para realizar unas sencillas comprobaciones con la intención de calcular la probabilidad de que un dominio dado utilice técnicas de fast-flux para utilizar múltiples ordenadores infectados como parte de la propia plataforma de control y distribución del malware, dificultando así en gran medida que se pueda rastrear bien la botnet. Antes de nada, veremos un ejemplo de dominio de fast-flux, en cuanto a arquitectura DNS se refiere:
Imagen 1: Dominio fast-flux
Como vemos en la imagen, el subdominio www.keyboardcatzz.com resuelve a multitud de direcciones IP distintas que corresponden a diversos sistemas autónomos de BGP y utilizan un TTL realmente bajo, tan sólo 300 segundos. Tal y como explican Thorsten Holz, Christian Gorecki, Konrad Rieck y Felix C. Freiling en su paper “Measuring and Detecting Fast-Flux Service Networks”es posible calcular la probabilidad de que un dominio utilice fast-flux en base al número de direcciones IP que resuelvan y, directamente relacionado con ellas, los sistemas autónomos a los que pertenezcan con altas probabilidades de acierto. Para ello, se solicita el dominio en cuestión y se almacenan las direcciones IP, se espera a que expire el TTL del DNS para que sea necesario resolverlo de nuevo en caso de que estuviese cacheado (hay un TTL máximo establecido para considerarse demasiado elevado como para usarse en redes fast-flux, aunque esto no siempre es así y se puede ajustar en el programa fácilmente). pffdetect es una implementación en Python de las métricas y procedimientos explicados en el paper y presenta las siguientes características:
-
Posibilidad de procesar un único dominio o lista de ellos
-
Múltiples formas de comprobar el AS de una dirección IP, entre las que se encuentran los servicios de Team-Cymru y la base de datos de MaxMind
-
Posibilidad de usar múltiples cores
-
Posibilidad de ejecutarse como aplicación de consola o importarse como módulo
De los distintos métodos de comprobación de AS el más rápido es, lógicamente, el uso de base de datos local y, después, el uso de consultas DNS. A continuación, pongo un ejemplo de uso para comprobar un único dominio (hay que tener en cuenta que las comprobaciones pueden tardar bastante, dependiendo del TTL utilizado en el dominio):
Imagen 2: Comprobación de dominio con pffdetect
Como se ve, el dominio analizado utiliza fast-flux para encubrir las direcciones IP reales utilizadas por el malware. Cabe destacar que los resultados no siempre son correctos, por ejemplo, estará muy condicionado según cómo roten las direcciones IP, si son de los mismos sistemas autónomos en las dos consultas realizadas, etc. Si queréis utilizarlo como módulo valdría con poner algo similar a lo siguiente:
#!/usr/bin/env python
import pffdetect
domains = ["www.buguroo.com","www.yahoo.com", "www.okrug2-bel.ru"]
fastfluxed = pffdetect.checkDomains(domains, ’8.8.8.8′, 1800, ‘DNS’, 10, 2)
El programa tiene todos los métodos documentados, así que es fácil saber los parámetros necesarios y modificarlo en caso de ser necesario.
Para todos aquellos que os interese el tema, os recomiendo leer el paper entero en https://pi1.informatik.uni-mannheim.de/filepool/research/publications/fast-flux-ndss08.pdf. Espero que encontréis útil el programa, cualquier duda, comentario o sugerencia será bienvenida, ¡saludos a todos! Podéis contactar con el autor a través de Twitter: https://www.twitter.com/z0mbiehunt3r
05/07/12 by Alejandro Nolla | Uncategorized | No Comments »
Antes de nada, quería felicitar a todo el grupo detrás de la ConectaCon y EnRed 2.0 por organizar tan estupendo, y necesario, evento y conseguir semejante asistencia. Cabe destacar que, tanto las jornadas como los talleres, eran totalmente gratuitos y de libre asistencia. El éxito fue tal que hubo que hacer unas reorganizaciones de última hora para los talleres, asistió muchísima más gente de la esperada y, aún así, la organización supo gestionar en todo momento las cosas de una manera perfecta.
Además, y como ponente del evento, quiero agradecer el cariño y la atención que desde un primer momento nos ofrecieron, consiguiendo siempre que nos sintiésemos mejor que en nuestra propia casa, desde aquí, os mando un caluroso abrazo.
Día I
El primer día estaba más orientado a aquellos profesionales que trabajan en el día a día con la tecnología de la información, siendo algo menos técnico y centrándose más en los aspectos de gestión de la seguridad de la información, un aspecto en ocasiones infravalorado pero totalmente imprescindible sin el que el resto de la seguridad de la información no podría sustentarse.
La primera ponencia vino de la mano de J.M Márquez quien, de una forma amena, hizo una breve introducción la Ley Orgánica de Protección de Datos (LOPD), explicando primero la historia de la misma para pasar a explicar algunos puntos “críticos” dentro de la norma y poner algunos ejemplos. Teniendo en cuenta que tan sólo disponía de una hora escasa y que el público objetivo era una clase abarrotada de estudiantes no puedo sino decir que hizo un trabajo excelente haciendo interesante la materia consiguiendo condensar los puntos clave y la esencia de la LOPD para que los asistentes tuviesen una impresión general de la misma.
A continuación se hizo un pequeño descanso y se procedió a preparar la conexión en remoto para el siguiente ponente: D. Blanco quien, a pesar de no poder trasladarse hasta el aula por motivos de trabajo, consiguió hacer un hueco en la agenda para brindar una ponencia sobre certificados digitales en las empresas y explicar cómo se encuentra actualmente el DNI digital y la integración del mismo a distintos niveles de servicios ofrecidos a través de distintas páginas web.
La siguiente ponencia nos vino de la mano de Eduardo Castellote de Panda Security, quien mostró de una manera global la situación actual de la seguridad y los ataques informáticos realizados a diario, la organización de las mafias encargadas de realizar distintos fraudes en Internet, los distintos “servicios” delictivos que ofrecen, las metodologías que emplean, etc.
Acto seguido, pasó a explicar el arduo trabajo que realizan desde Panda Security para estudiar y analizar miles de muestras de malware diariamente así como los avances en los ataques utilizados por los delincuentes para llevar a cabo los fraudes. Por último, explicó las tecnologías desarrolladas por Panda Security para paliar en la medida de lo posible todas las amenazas y brindar seguridad a sus usuarios en los distintos planos de seguridad de la información, haciendo especial hincapié en el uso de soluciones basadas en computación distribuida y escalable en Internet.
La última ponencia del día vino de la mano de J. Cantero, miembro del cuerpo de la Guardia Civil. En su ponencia explicó la organización y el funcionamiento de la Guardia Civil en las distintas áreas en las que actúan , todo ello desde el punto de vista de delitos relacionados con la seguridad de la información.
Durante el recorrido realizado por J. Cantero se vieron diversos delitos que perseguían y cómo se organizaban con otros cuarteles de la propia Guardia Civil para intentar manejar el tema de una forma controlada y centralizada.
Desde aquí quiero dar un abrazo y agradecer la labor que realizan persiguiendo lacra como es la pornografía infantil, un trabajo imprescindible y necesaria en el día a día.
Para finalizar el día contábamos con J.L. Verdeguer para dar un taller de auditoría de seguridad inalámbrica, a pesar de los “problemas” comentados al principio por la gran afluencia de gente a los talleres la organización lo gestionó bien y consiguió que se pudiese ver de forma teórica y con algo de práctica los distintos ataques y riesgos de hoy día concernientes a las redes inalámbricas.
Día II
El segundo día del evento estaba más orientado a estudiantes y gente con perfiles más del área técnica en lugar del área de gestión, condensando cuatro ponencias muy centradas en la propia seguridad de la información.
La primera ponencia la realizó Manuel Lucena y explicó el panorama actual de la seguridad en lo relativo a las comunicaciones electrónicas. Para ello primero desarrolló en el tiempo el concepto de comunicación, información y la relación entre ambas para pasar a explicar luego los tres pilares básicos de la información: confidencialidad, integridad y disponibilidad.
Después se realizó un pequeño descanso a media mañana y se pasó a la ponencia de un servidor, Alejandro Nolla. En la ponencia se vio de forma global e introductoria el concepto de auditoría de seguridad, viendo las diferencias existentes entre distintos tipos de auditoría, un ejemplo de proceso de auditoría de seguridad muy orientado al test de intrusión.
Como ejemplo de ataque se enseñó un ataque de inyección de código SQL y cómo, mediante un único vector de ataque, se puede afectar a los tres pilares de la seguridad de la información que comentaba Manuel Lucena: confidencialidad, integridad y disponibilidad.
A continuación José Luis Verdeguer expuso la situación actual de la seguridad en sistemas de VoIP, explicando la arquitectura básica necesaria para montar un sistema de VoIP y los distintos puntos susceptibles de ser atacados. Durante el transcurso de la ponencia explicó distintas herramientas para realizar auditorías de seguridad en sistemas de VoIP y realizó un par de demos de ataque a VoIP realmente interesantes. En la primera demo enseñó cómo un atacante podría obtener el control total de la centralita de VoIP e instalarle una puerta trasera para poder acceder al sistema a discreción del atacante mientras que en la segunda demo enseñó cómo el atacante podría intervenir en la conversación y afectar de manera arbitraria el transcurso de la misma, inyectando en el ejemplo un audio en medio del flujo de audio.
Para cerrar el evento contamos con Sebastián Guerrero, quien explicó diversos aspectos de seguridad en plataformas Android. Empezó dando unas pinceladas de la arquitectura del sistema operativo para pasar a la parte técnica de cómo analizar malware programado específicamente para Android. Para ello, se apoyó en un trabajo que él mismo realizó para analizar y rastrear el origen de una pieza de malware en concreto, demostrando el proceso desde el análisis del malware hasta la búsqueda de información al respecto en Internet.
Sebastián también mostró una técnica desarrollada por él con la que el malware podría aprovechar ciertas funcionalidades de Android para hacer que un usuario realizase acciones como el envío de mensajes a un número de tarificación extra sin que se diese cuenta mientras utilizaba un aplicación gancho como, por ejemplo, un juego.
El segundo y último taller de la jornada corrió a cargo de Sebastián Guerrero y en él explicó de una forma más práctica cómo analizar malware en plataformas Android de una forma práctica.
Para acabar la crónica no puedo sino decir que fue un evento realmente interesante en múltiples aspectos y animar a la organización a seguir haciendo el evento y dejar claro lo importante que es tener en cuenta la seguridad informática dentro del mundo actual.
Sin más, ¡nos vemos en la próxima ConectaCon!
04/09/12 by Mario Vilas | labs, tools | No Comments »
Hola a todos. En esta ocasión voy a presentar un plugin para el depurador OllyDbg / Immunity Debugger que va a facilitar la tarea de realizar la ingeniería inversa de un binario de Windows.
¿Qué es OllyDbg?
OllyDbg es un clásico depurador de binarios a bajo nivel para el sistema operativo Windows. Según muchos, es la herramienta ideal para hacer ingeniería inversa de programas de los que no disponemos del código fuente (por ejemplo, malware), y también es muy utilizado en el mundo del cracking.
Una de las características más atractivas que tiene es la posibilidad de cargar plugins. La mayoría están orientados a ayudar en el desempacado de binarios protegidos y evitar la detección del depurador por parte del código malicioso que estemos analizando, aunque los hay para muchas otras tareas.
¿Qué es Immunity Debugger?
Luego de varios años sin actualizaciones, y tras múltiples exploits publicados que no han sido corregidos por el autor, la empresa Immunity decidió comprar el código fuente para actualizarlo y mejorarlo. Así nació Immunity Debugger, que parece estar destinado a reemplazar al viejo Olly, especialmente en el terreno del exploiting que es donde se están concentrando más las nuevas características y los nuevos plugins.
¿La pega? Que los viejos plugins de OllyDbg en general ya no funcionan más. Si se dispone del código fuente se pueden actualizar e incluso hacer que funcionen en ambos. Si no, la cosa está más complicada, aunque hay una herramienta que ayuda bastante.
El plugin que presento hoy funciona correctamente en ambos programas. 
¿Para qué sirve este plugin?
OllyDbg ya tiene sus años, y aunque se sigue usando no siempre ha envejecido con gracia. 
Uno de sus puntos flacos es el soporte de ayuda de Windows.
Me explico. Al analizar un binario en Windows normalmente veremos código ensamblador y llamadas a funciones de la Win32 API, que es la interfase de programación de bajo nivel en Windows. Las funciones de la API son muchas y es imposible memorizarlas todas, por lo que es imprescindible poder consultar la documentación de Microsoft para saber qué hace cada una, qué parámetros llevan, etc.
Ahora bien. OllyDbg ya permitía desde sus comienzos consultar la documentación de Microsoft gracias a un archivo llamado “WIN32.HLP“, que venía con la SDK de Windows NT, y contenía la documentación más completa y detallada… de aquel entonces. Pero ya pasaron varias versiones de Windows y unos cuantos años, Microsoft dejó de dar soporte a ese manual para dar paso a la documentación online de la MSDN (Microsoft Developer Network), y lo que ocurre ahora es que al consultar la ayuda desde el Olly muchas de las cosas que buscamos no aparecen. 
Este plugin viene a llenar ese vacío. Al instalarlo, cuando OllyDbg intente acceder a WIN32.HLP para mostrar la documentación, el plugin lo intercepta y lanza el navegador web en la página correspondiente de la documentación online.
¿Cómo se instala este plugin?
Es simple, hay que descargar el archivo zip, extraer el plugin (OllyMSDN.dll) y copiarlo a la carpeta de instalación del depurador.
En OllyDbg esta carpeta suele ser “C:\Program Files\OllyDbg” (en castellano C:\Archivos de Programa\OllyDbg”).
En Immunity Debugger la carpeta suele ser “C:\Program Files\Immunity Inc\Immunity Debugger” (en castellano nuevamente reemplazar “Program Files” por “Archivos de Programa”).
El siguiente paso es cargar el depurador, y desde el menú “Help” ir a la opción “Select API help file”. Allí hay que, o bien seleccionar el viejo WIN32.HLP (aunque no se vaya a usar), o al menos un archivo cualquiera que se llame exactamente igual (el contenido da lo mismo). El nombre es importante, porque es la manera en que el plugin se da cuenta de que el usuario está intentando consultar la documentación de Microsoft y no, digamos, la ayuda del propio OllyDbg.
Una vez hecho esto, ya está completa la instalación.
¿Cómo se usa este plugin?
Se usa exactamente igual que el viejo archivo WIN32.HLP. Es decir:
Para acceder a la documentación, vamos al menú “Help” y seleccionamos la opción “Open API help file”.
Para ver la ayuda de una llamada API en concreto, hacemos click derecho sobre la línea de código ensamblador y seleccionamos la opción “Help on symbolic name”.
¿Dónde consigo este plugin?
Se puede comprar por el módico precio de… nah, mentira, es completamente gratuito!
Se descarga siguiendo este link: OllyMSDN.zip
El archivo zip contiene el binario precompilado para Windows y el código fuente, liberado bajo la licencia GPL v2. El fuente compila bajo Visual Studio 2008, no lo he probado con otros compiladores.
Bueno, eso es todo por hoy. Que les aproveche!
Sígueme en Twitter:
@Mario_Vilas | Linkedin:
http://es.linkedin.com/in/mariovilas
04/03/12 by Rubén Garrote García | hacking, programación segura, secure programming | No Comments »
Introducción
En este artículo vamos a explicar los detalles de la vulnerabilidad CVE-2011-4130 basándonos el advisory oficial.
La finalidad de este artículo es permitir al lector poder reproducir la excepción de violación de segmento mediante la cual es posible tomar el control de la aplicación y ejecutar código tal y como se verá en las siguientes partes de este artículo.
Preparando la mesa de trabajo
La vulnerabilidad afecta a las versiones de ProFTPd anteriores a 1.3.3g ó 1.3.4. Así que vamos a utilizar como servidor de pruebas un Ubuntu Desktop 10.04-LTS, ya que en su repositorio a día de hoy la versión actual es la 1.3.2c afectada por la vulnerabilidad en cuestión.
Para el código fuente de la aplicación, he descargado la 1.3.2e también vulnerable, por lo que nos sirve igualmente.
Explicación de la vulnerabilidad
Tal y como podemos ver en el advisory oficial la vulnerabilidad se produce al manejar incorrectamente el pool de estados para los comandos introducidos por el usuario.
El servidor FTP permite ejecutar acciones solicitada por el cliente mientras atiende nuevas peticiones. Para ello utiliza un pool donde va almacenando la lista de estados sobre los comandos solicitados por el cliente. De esta forma puede llevar un control de las peticiones que le quedan por atender. Cuando recibe un comando, guarda el estado en el pool mientras lo ejecuta y sigue recibiendo comandos del cliente. Una vez finalizan las tareas, el servidor restaura el estado para poder indicar al cliente el resultado y continuar atendiendo más comandos.
El problema sucede al solicitarle una petición, y mientras este la atiende, enviarle otra petición con un comando no esperado, por ejemplo un comando inexistente. En este caso, el servidor sale de una función sin restaurar el estado del pool y la lista de estados queda descompensada, al restaurar el estado anterior a este, la lista esta corrupta y cuando finalmente se intenta acceder al dicho estado se hace sobre un puntero ya liberado, produciéndose el Use-After-Free.
Para más detalles en el código, se puede ver como sucede esto en la función pr_cmd_dispatch_phase():
src/data.c:672
int pr_cmd_dispatch_phase(cmd_rec *cmd, int phase, int send_response) {
…
pool *resp_pool = NULL;
…
resp_pool = pr_response_get_pool(); // XXX: Almacena el pool actual
/* Set the pool used by the Response API for this command. */
pr_response_set_pool(cmd->pool); // XXX: Establece el pool a usar
…
if (phase == 0) { // XXX: pr_cmd_dispatch lo invoca con phase=0
/* First, dispatch to wildcard PRE_CMD handlers. */
success = _dispatch(cmd, PRE_CMD, FALSE, C_ANY);
if (!success) /* run other pre_cmd */
success = _dispatch(cmd, PRE_CMD, FALSE, NULL);
if (success < 0) { // XXX: Si ha ocurrido un error
/* Dispatch to POST_CMD_ERR handlers as well. */
_dispatch(cmd, POST_CMD_ERR, FALSE, C_ANY);
_dispatch(cmd, POST_CMD_ERR, FALSE, NULL);
_dispatch(cmd, LOG_CMD_ERR, FALSE, C_ANY);
_dispatch(cmd, LOG_CMD_ERR, FALSE, NULL);
pr_response_flush(&resp_err_list);
return success; // XXX: Sale sin restaurar el pool inicial
}
…
/* Restore any previous pool to the Response API. */
pr_response_set_pool(resp_pool); // XXX: Restaura el pool inicial
return success;
}
Según el código anterior es posible salir de la función apuntando al pool cuyo comando es uno inexistente introducido por nosotros, en lugar de salir apuntando al pool que tenía antes de invocar dicha función. Esto provoca un error al intentar restaurar el pool anterior a este.
Para poder reproducir la vulnerabilidad es necesario llevar al servidor en un estado donde tenga que atender un nuevo comando mientras realiza otras acciones. En un servidor FTP esto puede provocarse al realizar una transferencia de datos, ya sea subiendo información al servidor o bien descargándola de la misma.
Cuando ejecutamos un comando de transferencia de información para descargar (RETR) o para subir información (STOR) la función encargada de manejar dichos datos es pr_data_xfer() que se muestra a continuación. Esta función es la encargada de transferir los datos y de analizar los comandos que hay en el pool de estados para ver si es capaz de atenderlos sin entrar en conflicto con la transferencia actual tal y como se puede ver en el código siguiente:
src/data.c:875
int pr_data_xfer(char *cl_buf, int cl_size) {
…
//XXX: Comandos que no pueden ser atendidos durante la transferencia
if (strcmp(cmd->argv[0], C_APPE) == 0 ||
strcmp(cmd->argv[0], C_LIST) == 0 ||
strcmp(cmd->argv[0], C_MLSD) == 0 ||
strcmp(cmd->argv[0], C_NLST) == 0 ||
strcmp(cmd->argv[0], C_RETR) == 0 ||
strcmp(cmd->argv[0], C_STOR) == 0 ||
strcmp(cmd->argv[0], C_STOU) == 0 ||
strcmp(cmd->argv[0], C_RNFR) == 0 ||
strcmp(cmd->argv[0], C_RNTO) == 0 ||
strcmp(cmd->argv[0], C_PORT) == 0 ||
strcmp(cmd->argv[0], C_EPRT) == 0 ||
strcmp(cmd->argv[0], C_PASV) == 0 ||
strcmp(cmd->argv[0], C_EPSV) == 0) {
pool *resp_pool;
…
} else if (strcmp(cmd->argv[0], C_NOOP) == 0) {
…
} else { // XXX: Comandos que si pueden ser atendidos
pr_cmd_dispatch(cmd); // XXX: Atiende el comando
…
destroy_pool(cmd->pool); // XXX: Destruye el pool
Como se puede ver, si durante la transferencia se introduce un comando inexistente, y pr_cmd_dispatch() sale sin restaurar el pool, como hemos visto anteriormente, en este punto se destruye el pool anterior al que acabamos de atender.
Para provocar la excepción solo necesitamos saber dónde se va a utilizar este pool que ha sido liberado inadecuadamente. Para ello vemos como pr_data_close() que es invocado al finalizar la transferencia hace una llamada a pr_response_add():
src/data.c:616
void pr_data_close(int quiet) {
…
if (!quiet)
pr_response_add(R_226, _(“Transfer complete”)); //XXX
}
es en esta función, encargada de mostrar el mensaje de transferencia finalizada, dónde se hace uso del pool liberado y se produce la vulnerabilidad Use-After-Free.
src/response.c:143
void pr_response_add_err(const char *numeric, const char *fmt, …) {
…
// XXX: Vemos como se accede al pool (res_pool) ya liberado
resp = (pr_response_t *) pcalloc(resp_pool, sizeof(pr_response_t));
resp->num = (numeric ? pstrdup(resp_pool, numeric) : NULL);
resp->msg = pstrdup(resp_pool, resp_buf);
…
}
Para provocar el error, debemos enviar un comando incorrecto cuyos argumentos sean matcheados por el filtro. Para ello debemos consultar la expresión regular que filtra los argumentos antes de enviárselos al comando y así poder formar el comando que buscamos. Esto podemos verlo en el fichero de configuración /etc/proftpd.conf dónde podemos ver la siguiente línea:
/etc/proftpd/proftpd.conf:30
DenyFilter \*.*/
Por ello cualquier argumento que cumpla esta condición, servirá para alcanzar el código vulnerable y provocar la excepción.
NOTA: Es curioso ver como en el código fuente, aparece el siguiente comentario del desarrollador. Lo que indica que eran conscientes de que existía un error aquí. Buscar este tipo de comentarios en el código fuente de las aplicaciones es una manera más de descubrir vulnerabilidades ;D
src/main.c:659
int pr_cmd_dispatch_phase(cmd_rec *cmd, int phase, int flags) {
…
/* Get any previous pool that may be being used by the Response API.
*
* In most cases, this will be NULL. However, if proftpd is in the
* midst of a data transfer when a command comes in on the control
* connection, then the pool in use will be that of the data transfer
* instigating command. We want to stash that pool, so that after this
* command is dispatched, we can return the pool of the old command.
* Otherwise, Bad Things (segfaults) happen.
*/
Estrategia a seguir
Para poder reproducir la excepción necesitaremos conectarnos al servidor, autenticarnos, y solicitarle un fichero de datos. Durante el lapso de tiempo en que recibimos los datos del fichero debemos introducir un comando no esperado por el servidor.
Para poder hacer esto de manera eficiente, deberemos programar un par de scripts que lo hagan por nosotros. El primero pone a escuchar un puerto superior al 1024, tras recibir la conexión lee 2 bytes, espera 5 segundos para permitir al otro script enviar el comando inexistente y tras ese lapso de tiempo continua recibiendo los datos para finalizar la conexión. Obviamente el fichero solicitado debe existir.
Por otro lado otro script que conecte con el servidor, se autentica, le dice al servidor la IP y el puerto al que debe enviar los datos del fichero y le pida que lo envíe. Tras esta acción es cuando puede enviar el comando inexistente durante los 5 segundos que le permite el primer script.
Script que queda a la escucha para recibir los datos del servidor (dataServerExploitFTPd.py):
http://pastebin.com/Uuk9LwjN
Script que envía los comandos al servidor para provocar la excepción (exploitProftpd.py).
http://pastebin.com/iJAFCd8e
Capturando la excepción
En primer lugar vamos a levantar el servidor ProFTPd y vamos a comprobar que está funcionando. Para ello basta con utilizar un cliente FTP cualquiera y acceder al mismo con las credenciales pertinentes. Para poder provocar la excepción, es necesario crear un fichero en el home del usuario FTP con el nombre ‘nada‘ (este será el fichero a descargar por el exploit) con algunos bytes de contenido. Una vez hemos hecho esto podemos pasar a ejecutar los scripts. Una vez finalizado, podemos ver el siguiente mensaje tras ejecutar el comando dmesg:
usuario@ubuntu:~$ dmesg
…
[86470.833018] proftpd[5106]: segfault at 10 ip 0000000000415efe sp 00007fff3dcde270 error 4 in proftpd[400000+97000]
Ahora vamos a capturar dicha excepción con el debugger. Primero vemos los procesos activos de ProFTPd:
usuario@ubuntu:~$ ps -aux | grep proftpd
Warning: bad ps syntax, perhaps a bogus ‘-’? See http://procps.sf.net/faq.html
proftpd 2242 0.0 0.1 73968 1932 ? SNs Mar11 0:01 proftpd: (accepting connections)
Cuando se conecta un nuevo cliente, se crea otro nuevo proceso con un id más alto, este es el proceso que nos interesa.
usuario@ubuntu:~$ ps -aux | grep proftpd
Warning: bad ps syntax, perhaps a bogus ‘-’? See http://procps.sf.net/faq.html
proftpd 5595 0.0 0.1 75680 1996 ? Ss 17:17 0:00 proftpd: (accepting connections)
proftpd 5683 0.0 0.2 75680 2684 ? S 17:38 0:00 proftpd: connected: ::ffff:192.168.1.11 (::ffff:192.168.1.11:40222)
Para que nos dé tiempo de hacer todo rápido, vamos a crear un fichero de comandos para GDB (gdbCommands) que inicialmente no existe, con estos dos únicos comandos:
usuario@ubuntu:~$ echo handle SIGSEGV nopass >> gdbCommands
usuario@ubuntu:~$ echo c >> gdbCommands
Ahora vamos a ejecutar el primer script (dataServerExploitFTPd.py) en una shell, abrimos otra shell y lanzamos el segundo script (exploitProftpd.py) y durante el lapso de tiempo que nos da el primer script, abrimos una tercera shell (como root) y ejecutamos el siguiente comando:
root@ubuntu:/home/usuario# gdb –p `pidof proftpd | cut –c’ ‘ –f 2` -x gdbCommands
Con esto nos attacheamos al proceso creado para atender nuestros comandos ftp, y ejecuta automáticamente los comandos del fichero (gdbCommands), lo único que hace es decirle al debugger que no pase las señales de SIGSEGV al programa, ya que queremos que las capture el debugger para analizarlo y luego le decimos que continúe con el proceso. Tras unos segundos finaliza la transmisión de ficheros y podemos ver lo siguiente:
root@ubuntu:/home/usuario# gdb -p `pidof proftpd | cut -d’ ‘ -f1` -x gdbCommands
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-linux-gnu”.
Para las instrucciones de informe de errores, vea:
.
Adjuntando a process 5713
Leyendo símbolos desde /usr/sbin/proftpd…(no se encontraron símbolos de depuración)hecho.
…
0x00007f84881defd3 in select () from /lib/libc.so.6
Program received signal SIGSEGV, Segmentation fault.
0x0000000000415efe in ?? ()
(gdb) bt
#0 0x0000000000415efe in ?? ()
#1 0x000000000041700a in pstrdup ()
#2 0x000000000042d927 in pr_response_add ()
#3 0×0000000000450985 in ?? ()
#4 0x000000000042fbc2 in pr_module_call ()
#5 0x00000000004133a6 in ?? ()
#6 0x00000000004139ab in pr_cmd_dispatch_phase ()
#7 0x0000000000414fdc in ?? ()
#8 0x00000000004107ae in ?? ()
#9 0×0000000000412769 in ?? ()
#10 0x000000000041494d in main ()
(gdb) i r
rax 0×0 0
rbx 0x127e130 19390768
rcx 0×0 0
rdx 0×0 0
rsi 0×4 4
rdi 0x127e130 19390768
rbp 0x127e130 0x127e130
rsp 0x7fff81136690 0x7fff81136690
r8 0x47dc02 4709378
r9 0×101010101010101 72340172838076673
r10 0x7f848847e14c 140207198822732
r11 0x7f8488185962 140207195707746
r12 0×4 4
r13 0×69 105
r14 0x7fff811368bc 140735358920892
r15 0xc 12
rip 0x415efe 0x415efe
eflags 0×10202 [ IF RF ]
cs 0×33 51
ss 0x2b 43
ds 0×0 0
es 0×0 0
fs 0×0 0
gs 0×0 0
(gdb) x/8i $rip
=> 0x415efe: mov 0×10(%rcx),%rdi
0x415f02: jle 0x415f23
0x415f04: lea -0×1(%rsi),%r12d
0x415f08: and $0xfffffffffffffff8,%r12d
0x415f0c: add $0×8,%r12d
0x415f10: movslq %r12d,%rbp
0x415f13: lea (%rdi,%rbp,1),%rax
0x415f17: cmp (%rcx),%rax
(gdb) set disassembly-flavor intel
(gdb) x/8i $rip
=> 0x415efe: mov rdi,QWORD PTR [rcx+0x10]
0x415f02: jle 0x415f23
0x415f04: lea r12d,[rsi-0x1]
0x415f08: and r12d,0xfffffffffffffff8
0x415f0c: add r12d,0×8
0x415f10: movsxd rbp,r12d
0x415f13: lea rax,[rdi+rbp*1]
0x415f17: cmp rax,QWORD PTR [rcx]
Como se puede ver en el código que ha producido la excepción, se intenta acceder al registro RCX cuyo valor es 0.
En el próximo capítulo
Ahora que ya hemos sido capaces de analizar la vulnerabilidad revisando el código fuente y conseguido reproducir la excepción, pasamos a cosas más interesantes, analizar con el debugger como trabajan las funciones que reservan y liberan los pool y de qué manera podemos aprovechar esto para ejecutar código ;D Así que ir preparando vuestro entorno de trabajo que aún nos queda lo más duro.
—
Follow me on Twitter: @Boken_
