Parcheando código con GDB

Hace un par de días, durante un reto de seguridad, nos encontramos con la situación de tener que modificar con GDB el código de un binario para que realizara las acciones que nos interesaban y no para las que había sido programado; esto suele usarse en los retos tipo “crack me” o “patch me”. Todo sea dicho, al final no era la solución al reto, pero como todo reto, se suelen probar distintas opciones.

De forma resumida tenemos un programa con la función principal y dos funciones adicionales declaradas. En la función principal se llama solo a una de las dos funciones, en este caso a la función que llamaremos “malo”, pero nosotros necesitábamos que en vez de llamar a esa función llame a la otra función, la que llamaremos “bueno”.

Un ejemplo del código en C sería el siguiente, al que denominaremos “prueba.c”:

#include
#include
//Funciones auxiliares
void bueno(void) { printf("SIIII");}
void malo(void) { printf("Noooo");}
//Función principal que llama a la funcion malo
void main(void){malo();}

Nuestro objetivo era que el programa, en lugar de llamar a la función malo en el main, llamara a la función bueno. Para el reto teníamos únicamente GDB como debugger. Para la entrada usaremos el código anterior por estar más simplificado y resultar más claro.

Teniendo en cuenta que el código anterior se ha escrito en el fichero “prueba.c”, hay que seguir los siguientes pasos para compilar y cargar el binario en GDB:

$ gcc -o prueba prueba.c
$ gdb prueba

 
Una vez accedido a GDB le indicaremos que queremos usar el formato Intel en vez del AT&T seleccionado por defecto (me gusta más, para gustos colores o sabores):

$ set disassembly-flavor intel

El siguiente paso consistirá en ver el código del programa, teniendo encuenta que las pruebas se hacen sobre un entorno de 64 bits (por eso las direcciones son tan largas):

(gdb) disas main
Dump of assembler code for function main:
0x0000000000400514 < +0>: push rbp
0x0000000000400515 < +1>: mov rbp,rsp
0x0000000000400518 < +4>: call 0x4004fc <malo>
0x000000000040051d < +9>: pop rbp
0x000000000040051e < +10>: ret
End of assembler dump.

NOTA: “disas” viene de la orden “disassemble” pero se puede usar de esta forma porque no hay órdenes que empiecen por “disas” y no es necesario escribir la orden completa… es igual que ocurre en los cacharritos CISCO :)

Como vemos la llamada a la función malo, mediante CALL, está en posición “0×400518″, la cual apunta a la dirección “0×4004fc” donde se encuentra la primera instrucción de la función malo, tal como se muestra a continuación:

(gdb) disas malo
Dump of assembler code for function malo:
0x00000000004004fc < +0>: push rbp
...
0x0000000000400512 < +22>: pop rbp
0x0000000000400513 < +23>: ret
End of assembler dump.

El siguiente paso es analizar el tipo de CALL de la función principal (main), identificando el tipo de OP Code de la función; en nuestro caso se mostrarán los 8 bytes a partir del CALL:

(gdb) x/8xb 0x400518
0x400518 : 0xe8 0xdf 0xff 0xff 0xff 0x5d 0xc3 0x90

Vemos que el primer byte es 0xe8, que corresponde con el OP Code del CALL a dirección relativa Call32(). Dicha llamada consta de 5 bytes; el primero es el OPCode representado como “0xe8″ identificativo de la llamada y los siguientes 4 bytes es la dirección donde se encuentra la función que se desea llamar. Por tanto para ver correctamente esta instrucción será necesario visualizar solo los 5 primeros bytes:

(gdb) x/5xb 0x400518
0x400518 : 0xe8 0xdf 0xff 0xff 0xff

Donde tenemos el Op Code 0xe8 y la dirección “0xdf 0xff 0xf 0xff”. Como este ordenador es un LE hay que darle la vuelta: es decir, la dirección real es ” 0xff 0xff 0xff 0xdf”. Esto se puede realizar cambiando el carácter “b” de byte por el de word “w” e indicando la posición de memoria donde empieza la dirección que se quiere tratar, es decir, la dirección del CALL + 1 (quitamos el OP Code 0xe8):

(gdb) x/xw 0x400519
0x400519 : 0xffffffdf

Y la pregunta que se estarán realizando, ¿de dónde sale ese dato? Pues ese dato es el valor negado de la diferencia (offset) entre el final de la llamada del CALL y la función que se quiere llamar:

Not (OFFSET) = pos pre CALL + tam instrucción call - F(x) a saltar

¿Lioso? Veámoslo por partes. Tenemos de offset este valor “0xffffffdf”, con lo que la operación NOT sería:

0xdf -> 1101 1111 (el not de esto) -> 0010 0000 -> 0x20

Por tanto el NOT de “0xffffffdf” es “0×00000020″. Si sabemos que el Call se llama en la posición “0×400518″ y el tamaño de la instrucción CALL son 5 bytes, entonces sabemos que la f(x) termina en la posición “0×40051c”; cuidado porque el byte “518” ya es el primer byte del CALL:

F(x) a saltar = pos pre CALL + tam instrucción call - Not (OFFSET)
F(x) a saltar = 0x400518 + 0x4 - 0x20 = 0x40051c - 0x20 = 0x4004FC

Es decir, la posición donde está la función malo que hemos identificado con anterioridad.

Ahora queremos modificar el CALL para que apunte a bueno. Para ello es necesario obtener la posición de la función bueno:

(gdb) disas bueno
Dump of assembler code for function bueno:
0x00000000004004e4 < +0>: push rbp
…

Ya sabemos que el último byte de CALL está en la posición “0×40051c”, por tanto:

0x40051c - 0x4004e4 = 0x38

Not de 0×38 = 0xFFFFFFC7, y como es necesario ponerlo en LE -> 0xC7 0xff 0xff 0xff

Si recordamos, en el CALL de la función principal teníamos la siguiente entrada “0xe8 0xdf 0xff 0xff 0xff” la cual apuntaba a malo, y ahora queremos sustituirla por 0xc7 0xff 0xff 0xff: solo necesitamos cambiar el segundo byte del call, es decir 0xdf por 0xc7. O sea, indicarle que el byte “0×400519″ valga 0xC7:

(gdb) x/xb 0x400519
0x400519 : 0xdf

Para realizar dicha operación es necesario usar “set” indicando que lo que se quiere sustiruir es un byte en la posición indicada:

(gdb) set *(unsigned char*) 0x400519 = 0xc7
Cannot access memory at address 0x400519

Como vemos ha fallado, no tenemos acceso a dicha posición de memoria, hagamos una triquimechuela poniendo un breakpoint en la instrucción previa al call y ejecutando el programa:

(gdb) break 0x0000000000400515
Function "0x0000000000400515" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (0x0000000000400515) pending.

Ejecutamos ahora el programa esperando a que se detenga en el break indicado, una instrucción antes del call:

(gdb) start
Temporary breakpoint 2 at 0x400518
Starting program: /home/moxilo/prueba
Temporary breakpoint 2, 0x0000000000400518 in main ()
(gdb) disas main
Dump of assembler code for function main:
0x0000000000400514 < +0>: push rbp
0x0000000000400515 < +1>: mov rbp,rsp
=> 0x0000000000400518 < +4>: call 0x4004fc <malo>
0x000000000040051d < +9>: pop rbp
0x000000000040051e < +10>: ret
End of assembler dump.

Ahora ya podemos aplicar el cambio y comprobar que la modificación se ha llevado a cabo al apuntar el call a la función bueno en vez de a la función malo:

(gdb) set *(unsigned char*) 0x400519 = 0xc7
(gdb) disas main
Dump of assembler code for function main:
0x0000000000400514 < +0>: push rbp
0x0000000000400515 < +1>: mov rbp,rsp
=> 0x0000000000400518 < +4>: call 0x4004e4 <bueno>
0x000000000040051d < +9>: pop rbp
0x000000000040051e < +10>: ret
End of assembler dump.

Como vemos ya apuntamos a la función bueno, por lo que si le decimos que “continue” mostrará el texto de la función buena (“SIIII”) y no el de la función mala:

(gdb) continue
Continuing.
SIIII[Inferior 1 (process 3897) exited with code 05]

Por tanto hemos parcheado el programa en ejecución con GDB, de tal forma que hemos obtenido la dirección de memoria de otra función, sustituyendo posteriormente la dirección de la llamada CALL por la de la función que nos ha interesado. Esto también se puede usar para sustituir instrucciones de códio que realizan ciertas comprobaciones que no nos interesa por NOPs (0×90), es decir, por “nada”.

PD: soy consciente de la poca actividad del foro, pero los 4 tomos de canción de hielo y fuego, el nombre del viento, el temblor de un hombre sabio, las 7 horas de inglés semanales y el GREM que lo tengo en dos semanas son los culpables.

¿Realmente importa la seguridad?

Hace unos meses estuve investigando un producto de software que te permite detectar posibles fugas de información mediante compendios de ciertos ficheros. Este programa tiene su parte comercial y su parte gratuita o comunitaria. Quería probar la parte gratuita para ver un poco el funcionamiento del mismos para decidir si el producto valía la pena. 

Lógicamente como todo producto nuevo quise documentarme de su funcionamiento, para validar si el producto cumplía todos los requisitos que necesitaba. Solo encontré enlace a la documentación para la parte comunitaria y no para la de pago. Para ello seguí los siguientes pasos:

1. Voy a la web oficial del producto: http://www.XXXX.com/
   
2. Desde la barra superior selecciono Products -> XXXX Comunity Edition llevándome al enlace siguiente: http://www.XXXX.com/XXXX-community-edition
   
3. En dicha web se muestra en el primer párrafo el siguiente texto:
   "You can checkout documentations from XXXX Documentation or from other sites."
   
4. Dicho enlace apunta a http://www.XXXX.com/documents ... bueno pues navego a dicho enlace y me veo que me redirecciona al siguiente enlace:
   http://www.XXXX.com/?controller=..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron_

Y yo, ¡vale! parece ser que se han cargado la Web o  la gente que mantiene la parte comunitaria les ha gastado una broma o cualquier cosa de ese tipo. Pues bueno, voy a notificar a un CERT español, CSIRT-cv, para que les informe, ya que, siendo un producto de seguridad no da una buna imagen... 

Pues bien, de eso hace dos meses, no he recibido noticia alguna, ni el CERT tampoco y llevan con ese enlace en su propia Web al menos 2 meses que fue cuando lo notifique. En cambio el blog sigue en marcha, ya que hay una noticia del 12 de Diciembre del 2011...

¿Como está el panorama de la seguridad, si los propios fabricantes de seguridad les importa un huevo la propia seguridad? Creo que me tendría que haber dedicado a programar Java, te hacen más caso, hay más trabajo, está mejor visto y te pagan mejor. Masajaker con la bara les tenia que crujir a todos. 

PD: he sustituido el producto por "XXXX" para evitar cualquier cosa, que tal como está el panorama ya ni una SOPA te puedes tomar sin que te siente mal.

-----


Madre, ¡cuanto tiempo ha pasado desde mi última entrada! siento la tardanza pero voy bastante liado con tema de papeleos, trabajo, los cuatro tomos de "canción de hielo y fuego" y el GREM. Sí, sí al final me decidi por el de reversing de malware en vez de por el de bastionado en entornos Windows.

¿Por qué? uiii como diría Guardiola que palabra más peligrosa. Pues la razón es simple, muchas veces cuando realizas un forense te encuentras con un bicho. Debes analizar ese bicho y comprobar su comportamiento a nivel de ingeniería inversa del código, pero mis conocimientos para realizar tal tarea no eran ni de lejos los adecuados. Por ahora tengo que decir que el GREM me está gustanto bastante. A ver si un día tengo tiempo y voy contando un poco sobre los certificados que estoy realizando ;)

Presentando Mail Malware Trap

A raíz de la entrada del correo electrónico donde se enlazaba a un troyano bancario, comencé a desarrollar un programita que tenía en mente desde hacía tiempo. Se trata de un recolector de Malware de correos electrónicos, encargado de acceder a distintas cuentas de correo, obtener el correo electrónico, almacenarlos en base de datos, y en caso de poseer adjuntos, ser analizados con la API de Virus total.

Veámoslo con más detenimiento. Primero será necesario disponer de una serie de sondas, correspondientes a cuentas de correo electrónico perteneciente en distintos servidores públicos como son Gmail, Yahoo o Hotmail, así como una serie de correos privados como por ejemplo el corporativo. Dichas cuentas de correo solo se usarán para recoger el correo que llegue a la bandeja de entrada y Spam. Para ello en ocasiones será necesario hacer filtros para trasladar el correo de la carpeta Spam a bandeja de entrada. Por ejemplo para Gmail sería necesario crearse un filtro de tipo texto con la siguiente entrada “is:spam” e indicar que debe enviarse como correo no leído a la bandeja de entrada. Con esto dispondremos de varias cuentas de correo distribuidas sobre distintos servidores de correo cuyo único objetivo es almacenar los correos de entrada.

Así, el recolector de malware lo que hará será conectarse a las cuentas para descargarse el correo nuevo y una vez obtenido insertará en una base de datos MySQL el correo descargado, indicando de qué servidor de correo lo ha descargado, a qué hora ha llegado, quién lo ha enviado, con qué asunto y con qué texto. Tanto el asunto como el texto se almacenarán en base64 en la base de datos.

El agente también comprobará si el correo electrónico tiene adjuntos. En caso de tener se descargará el adjunto conservando su nombre y lo almacenará en un árbol de sistema de ficheros compuesto por año, mes y identificador de correo de la base de datos. A su vez se insertará en la base de datos de que correo procede el adjunto, donde está almacenado, su comprobación MD5, si ha sido subido anteriormente a Virus Total y en caso afirmativo, se nos mostrará el resultado de los antivirus.

Veamos como funciona. En primer lugar será necesario disponer de una base de datos MySQL en el servidor donde instalemos el agente. Una vez dispongamos del MySQL será necesario crearnos el usuario y la base de datos mediante las siguientes órdenes:

$ mysql -u root -p
> CREATE database mailmalwaretrap;
> CREATE USER 'mailmalwaretrap'@'localhost' IDENTIFIED BY 'MiContrasenya';
> GRANT SELECT, INSERT, DELETE ON mailmalwaretrap.* TO 'mailmalwaretrap'@'localhost';

A continuación volcaremos el esquema de la base de datos, que podéis obtener de mailMalwareTrap.sql (los ficheros están al final del post):

$ mysql -u root -p < mailMalwareTrap.sql

Posteriormente configuraremos el agente, escribiendo en el fichero “mailMalwareTrap.conf” una línea por cada cuenta de correo que dispongamos, teniendo en cuenta que se deberá seguir el siguiente esquema “servidorCorreo|cuentaCorreo|contraseña”. Si por ejemplo nuestro servidor de correo es “pop.gmail.com”, la cuenta “lol@gmail.com” y contraseña “lolazo” el fichero será el siguiente:

# cat mailMalwareTrap.conf
pop.gmail.com|lol@gmail.com|lolazo

Para finalizar obtendremos el agente “mailMalwareTrap.py” donde será necesario tener instalado las dependencias de MySQL para Python.

Para el ejemplo que mostraremos usaremos una única cuenta de Gmail donde enviaremos desde otro servidor de correo adjuntando un fichero pdf que corresponde con el meterpreter. Una vez enviado ejecutaremos el script para que procese los correos nuevos. Se aconseja que se ponga el script en el crontab para que se ejecute cada hora:

$ mailMalwareTrap.py
Hay correos nuevos en "pop.gmail.com".
$

Si accedemos a la base de datos tabla “mail”, veremos que se ha insertado el nuevo correo con identificador “1”, correspondiente a la sonda “1”, que ha llegado a las 10:52 del 11 de Noviembre, cuyo asunto y texto están en base64 para evitar “sorpresas”:

Si analizamos la tabla malware veremos lo siguiente:

Malware con identificador 1, procedente del correo con ID 1, que se encuentra almacenado en “/tmp/result/2011_11/1/meterpreter.pdf”, que ya había subido con anterioridad a Virus Total, listado de los resultados de los distintos antivirus (la mayoría lo detectan), texto añadido por nosotros (en este caso está a NULL) y para finalizar la comprobación md5 del malware.
Si comprobamos a mano la comprobación md5 veremos que es la misma que hay almacenada en la base de datos:

$ md5sum /tmp/result/2011_11/1/meterpreter.pdf
062e7ecdc4a15f2f49cb5b2b09e5a4ea /tmp/result/2011_11/1/meterpreter.pdf
$

Como ven es una forma sencilla de tener un recolector de malware de las carpetas Spam de distintos servidores que permite analizar los riesgos que pueden acontecer en su infraestructura.
Como mejoras pendientes tengo dos puntos claramente identificados: el primero será buscar en el texto del correo posibles URLs y analizar con Virus Total si se tratan de URL con malas intenciones. Así mismo el segundo punto lo constituye una interfaz gráfica que permita gestionar los correos de forma más sencilla. Pero todo esto ya otro día ;)

Espero que les haya gustado la entrada, todo sea dicho, imagino que alguien habrá tenido la idea antes, pero sinceramente, yo creo que para aprender es necesario hacerlo uno mismo. Los ficheros pueden descargarlos directamente desde este enlace: mailMalwareTrap.rar.

PD: tengo pendiente de subirlo al subversión con la nueva actualización pero por problemas de tiempo me ha sido imposible, intentare que la segunda versión esté para Febrero pero entre GREM y canción de hielo y fuego estoy ocupado.

PD2: entrada escrita también para el blog de mi empresa SecurityArtWork.

Un correo ¿amigo?, no, troyano bancario

Ayer domingo mientras pensaba qué excusa poner a mi compañero Raúl por lo del partido del Levante ante el Valencia —donde todo sea dicho de paso claramente nos robaron— me llegó un correo electrónico con una supuesta oferta de trabajo, tal como podemos ver en la siguiente imagen:

El enlace apuntaba a la siguiente dirección “http://anyhub.net/file/5r_v-oferta_838as32-pdf.exe”, donde como puede verse juega con la terminación “pdf” pero tiene extensión “exe”. Al analizar la cabecera del fichero vemos el “MZ” inicial típico de un ejecutable Windows; claramente todo apunta a Malware. Al buscar cadenas de texto en el binario mediante la herramienta “strings” vemos que el ejecutable contiene texto como el siguiente:

Microsoft Internet Security Banking Connections.
…
El c
digo de seguridad CVV/CVC, es un c
digo formado por tres cifras que est
situado en la parte trasera de su tarjeta de cr
dito.
…

A la vista de estos primeros indicios, lo que hice fue introducir el fichero en una máquina virtual VMWare para ver qué es lo que realmente hace. Lo primero que observamos es que al binario le han puesto el icono de un PDF de Acrobat Reader para hacer pasar al fichero por PDF a ojos de un usuario inexperto:

Al hacer click sobre el fichero no se ejecuta aparentemente nada, simulando de esta manera que el fichero no se ha abierto correctamente. No obstante, si analizamos los procesos en ejecución vemos que realmente sí que se está ejecutando el programa:

Como hemos visto con la orden strings, parece ser que se trata de un troyano con claros síntomas de intentar obtener datos bancarios, por lo que ejecutamos Internet Explorer y comenzamos a navegar por distintas Webs, sin detectar nada anómalo hasta que entramos en una web bancaria, donde el navegador se cierra y nos aparece la siguiente ventana de Windows, bastante elaborada a nivel gráfico para simular ser una pantalla auténtica del sistema de seguridad de los sistemas Windows:

Al pinchar sobre “Aceptar” se abre una pequeña aplicación con título “Microsoft Internet Security Banking Connections”, tal como vemos en la siguiente captura:

Si se pincha sobre el botón inferior derecho “Activar a mi equipo la conexión segura…” se abre una nueva ventana donde se invita a introducir los datos de nuestra tarjeta de crédito. En nuestro caso se introdujeron (obviamente) datos falsos:

Tras esto, capturamos el tráfico de red que se generaba al hacer click sobre “Activar”, obteniendo como resultado que el malware emplea el recurso “send.php” de la web “elequipodelbarrio.com.ar”, enviando los datos de la tarjeta de crédito en la variable “data” por POST mediante protocolo HTTP. Esto puede verse en la siguiente captura de pantalla:

 Al acceder a la web “elequipodelbarrio.com” vemos que aparenta ser una Web legítima con comentarios de varias personas incluidos, tal como se puede ver en la siguiente imagen:

Lo que hace pensar en dos posibles opciones: que la web haya sido comprometida o que se trate de una falsa web para no generar alarma. En mi caso procedí a enviar la alerta al CSIRT-Cv para que gestionasen la alerta temprana.

Para finalizar indicar que se trata de un troyano “típico” sudamericano, más enfocado a intentar engañar al usuario inexperto con pantallas y un entorno gráfico bastante conseguido, que a emplear métodos realmente complejos como es el caso habitual de los troyanos rusos. Lo que me ha llamado la atención es que al subir el binario a VirusTotal no me indicó que hubiera sido subido con anterioridad por otro usuario, y a su vez, que solo 6 de los 42 antivirus hayan reconocido al Troyano como tal:

Me gustaría poder realizar un reversing del troyano para saber si reconoce la URL bancarias por dirección de URL, por ciertos caracteres de texto que identifican un banco o por cualquier otro motivo, pero por desgracia mañana me llega un libro muy esperado “El temor de un hombre sabio” y es una tarea que va a tener que esperar unos días.

PD: entrada publicada también en securityartwork (blog de mi empresa).
PD2: me confirman desde el CSIRT-cv que han cerrado la Web, un micro punto para los "buenos" xD

HoneyNet UML

A lo largo de estos últimos años hemos escrito sobre los honeypots y las ventajas que aportan a nuestra infraestructura. Por ello para intentar promulgar el uso de este tipo de herramientas he preparado un entorno virtual que emula varios honeypots de distintas clase formando una red completa: una honeynet.

Como tecnología de virtualización he escogido User Mode Linux por estar bastante familiarizado con ella, debido a que fue la opción escogida en mi proyecto de fin de carrera.

Pero no solo por esto, ya que UML tiene una ventaja muy importantes respecto al resto de tecnologías: la máquina virtual es ejecutada con permisos de usuario sin privilegios, y por tanto, en caso de que un atacante consiga saltar al entorno anfitrión, éste accedería como usuario no privilegiado, es decir, sin ser root. De ahí su nombre, User Mode, ya que se ejecuta en el espacio de usuario y no en el espacio del kernel.

Como se puede ver en el siguiente diagrama, la Honeynet UML ha sido dividida en tres subredes: red de baja interacción, red de alta interacción y red de monitorización.

• La red de baja interacción está formada por dos máquinas virtuales y un Hub UML. La primera tiene configurado un HoneyD con 3 plantillas diferentes: Solaris, Windows Server 2003 y un Cisco ASA. A su vez se ha empleado el honeypot Kippo que simula una shell de SSH. La segunda máquina UML tiene instalado un Dionaea que recientemente analizó Nelo.

• La red de alta interacción está compuesta por una máquina virtual y un Hub UML. En ésta se ha instalado un honeypot de alta interacción (HIHAT) sobre un PhpMyAdmin.

• La red de monitorización está compuesta por una máquina virtual y un Hub UML. La máquina UML “Monit” tiene instalado una consola centralizada por Web con un OSSEC, Nagios3, Syslog centralizado , monitorización del tráfico de red, consola de gestión HIHAT y un Snort 2.9.1.2 con DAQ 0.62 que analiza el tráfico de las redes de baja y alta interacción.

Para poder ejecutar este entorno es necesario configurar primeramente el equipo anfitrión para crear las tres interfaces del entorno y habilitar el Masquerade de las máquinas virtuales:

# /honeynet/sbin/setup.sh on
 Making Taps...
  Tap0... [OK]
  Tap1... [OK]
  Tap2... [OK]
 Internet...  [OK]

Una vez configurado las tres interfaces ya podemos lanzar la red virtual como usuario no privilegiado mediante la siguiente orden:

$ /honeynet/bin/honeynet.sh on

 
Dando como resultado la siguiente imagen, donde podemos ver a la izquierda las cuatro consolas de las cuatro máquinas virtuales UML, en la parte central superior la ejecución del script de la honeynet, en la parte central inferior las 4 terminales de las máquinas virtuales y por último a la derecha la consola de alertas BASE (Snort) notificando de conexiones a la MySQL de HiHat:

Para facilitar la administración he creado una consola web centralizada en el entorno de monitorización que nos permite gestionar las alertas generadas:

• Entorno BASE que nos permite gestionar las alertas de Snort.
• Interfaz Web de OSSEC para gestionar las alertas del HIDS.
• Gestión de las notificaciones del Syslog de todos los honeypots distribuidos mediante Rsyslog y LogAnalyzer.
• Monitorización de la disponibilidad del entorno con Nagios3.
• Status que muestra el estado de la red: que tipo de tráfico, paquetes perdidos, clasificación de IPs conectadas, etc.

Tal como se ilustra en la siguiente imagen (al pinchar sobre la imagen, ésta se abrirá en una nueva ventana en tamaño grande):

He intentado subir el entorno a algún servidor para que únicamente con descargarse el fichero, descomprimirlo y ejecutarlo, tal como hemos mostrado en las capturas de pantalla, tendríamos una Honeynet completa en nuestro entorno, pero el fichero completo ocupa 6 GB y me ha sido imposible alojarla en un servidor.

De forma temporal he subido los ficheros necesarios a Google Code, donde podéis descargar desde este enlace los scripts necesarios para la ejecución y configuración de la honeynet. Para crear las máquinas UML “solo” tenéis que seguir estos pasos, que todo sea dicho, es un poco quick and dirty con un inglés sin comentarios ya que la wiki fue creada en dos horas…

Si alguien tiene especial interés existe la posibilidad de subir el proyecto a Megaupload o algún otro servidor que permita alojar un fichero de 6 GB. No me gusta nada esta idea pero visto lo visto no veo otra opción.

Para finalizar indicar que el proyecto está abierto a cualquier persona que quiera colaborar, ya que —sea dicho de paso— toda la colaboración que la “comunidad” muestra en aspectos de hacking y reversing brilla por su ausencia en materia de defensa de entornos. Por alguna razón desconocida (corramos un tupido velo) en general son más populares las estrategias y técnicas de ataque que las de defensa. Vayan ustedes a saber porqué.

PD: entrada publicada para securityartwork.

Fijación de sesión: Cookie (III)

Cuando la sesión se encuentra alojada en la cookie resulta mucho más difícil de explotar, debido a que cualquier navegador Web básico emplea la protección de mismo origen o “origin server”, donde un recurso web solo puede modificar atributos si ese recurso pertenece a su mismo dominio, puerto y protocolo, es decir, el servidor atacante no puede modificar la cookie del servidor víctima, y por tanto, no podrá fijar su sesión a la víctima.

Aún así existen distintas formas de intentar explotar una fijación de sesión almacenada en una cookie:

1. Si el servidor también es vulnerable a un XSS… ¿para qué voy a explotar un XSS para fijar una sesión cuando con explotar únicamente el XSS puedo obtener directamente la sesión empleada por la víctima?

2. Si puedo modificar el tráfico de red entre la víctima y el servidor vulnerable. Sinceramente ocurre lo mismo que en el caso anterior.

3. Pasar por GET la sesión y esperar un tratamiento incorrecto de la variable, ya que algunas aplicaciones Web si leen la variable de sesión por GET modifican la variable en la cookie.
4. Inyectando código HTML y JS en la cabecera del navegador, en especial “meta http-equiv” para intentar modificar la cookie. Esto funcionaba hace unos años, ahora mismo a mí no me ha dado buen resultado.

5. Intentado poner la cookie en la URL de tal forma que entre el recurso vulnerable y la cookie haya un salto de línea añadido “\r\n”, de modo que parezca que el servidor interprete la URL como URL más cabecera cookie. Era una vulnerabilidad relativamente antigua, tampoco me ha funcionado.

Por tanto, y desde mi punto de vista, intentar explotar una fijación de sesión por cookie es bastante difícil ya que se depende muchas veces de que el servidor, el navegador web de la víctima o la aplicación Web tenga alguna vulnerabilidad adicional.

Y ahora la pregunta que se estarán realizando, ¿por qué este post de una vulnerabilidad conocida y tanto interés en explotar la vulnerabilidad si la sesión va en una cookie? La respuesta es sencilla, en un viaje de vuelta en el tren me puse a jugar con una aplicación Web que sirve para practicar auditoría Web: DVWA. Como todas estas aplicaciones tienen una página de acceso al reto protegida por usuario y contraseña, la cual en principio no es vulnerable.

En caso de la DVWA creo que es vulnerable a fijación de sesión, ya que ésta no cambia antes y después de autenticarnos. Por precaución busqué si alguien había comentado algo previamente pero no he encontrado ningún comentario al respecto. Lógicamente esta aplicación no está enfocada a estar jamas en producción y su único propósito es docente. Aunque no tiene ningún tipo de criticidad puede servir como ejemplo.

Veámoslo en las siguientes dos capturas. Primero accedemos al recurso “login.php” sin estar autenticados, en la variable PHPSESSID vemos el valor de la sesión:

Una vez autenticamos el valor de la sesión continua siendo la misma:

Por desgracia al ir en la cookie la sesión me fue imposible explotar la vulnerabilidad. Para finalizar agradecer la ayuda proporcionada por Raúl Siles para intentar fijar la sesión en la cookie y recomendar esta presentación sobre fijación de sesión (PDF), a cuya charla en Barcelona tuve el placer de asistir. Nos vemos en la próxima entrada.


PD: entrada publicada para securityartwork.