El antiguo reto de la honeynet (I)

En esta y la siguiente entrada trataré el reto de análisis forense de la honeynet (proyecto Honeynet). Aunque antiguo, es la base de un análisis forense en un entorno Linux y creo que se pueden aprender muchas cosas. Existe una infinidad de soluciones tanto en blogs como en libros sobre la resolución del reto. En mi caso voy a seguir los pasos que seguí para la resolución de éste. Les advierto que tanto este como el siguiente artículo de la serie son algo largos, así que tómenselos con calma.

Comenzaremos montando una máquina virtual Linux. Primero instalaremos en el equipo anfitrión VirtualBox en su versión 4. A su vez nos descargaremos una imagen ISO de una distribución Linux. En mi caso he usado la Ubuntu 10.04. puesto que ya la tenia descargada. Una vez tengamos creada la máquina virtual instalaremos las LinuxAdditions.

Deberemos instalar, ya sea mediante fuentes o mediante repositorio, los siguientes programas: sleuthkit, foremost, mount, xxd, sorter, wget, md5sum y un editor (gedit, kate, kwrite, vim, nano, etc.).

Para finalizar nos creamos unos directorios donde gestionar el reto:

Ahora ya disponemos de una máquina virtual donde desarrollar el reto. ¡Comencemos!

Accedemos a la página web del reto y leemos toda la información que se nos proporciona. Una vez leía nos descargamos las fuentes desde la máquina virtual en el directorio “/reto/dd” con la siguiente orden:

Comprobamos que el fichero se ha descargado correctamente:

Nos da el mismo valor que el que indica en la web.

Desempaquetamos el fichero:

Junto con una serie de imágenes comprimidas, tenemos un fichero readme que contiene la información del punto de montaje de las imágenes y del hash md5 (que habrá que comprobarlo), tanto de las imágenes comprimidas (dd.gz) como el raw (dd).

Descomprimimos las imágenes:

Comprobamos que el valor del md5 es el mismo que el del readme:

Si no nos muestra un mensaje de error es que todo ha funcionado correctamente. El último paso consistirá en mover el fichero readme al directorio /reto/etc. Recordar que las imágenes (dd) deben de estar en el directorio /reto/dd.

Si hemos leído detenidamente el reto veremos que se nos proporciona los logs que generó la sonda de detección de intrusos, que en el caso del reto se trata de un Snort:

Claramente en los logs mostrados del Snort vemos que el supuesto ataque comenzo a las 23:11:06. Se realizó una consulta al RPC (puerto 111) del servidor (172.16.1.107) desde la ip 216.216.74.2. Posteriormente hubo intentos de conexión al puerto del Telnet (23). A las 23:11:51 se realizo una consulta de nuevo al RPC y inmediatamente se detecto un shellcode con NOPS. Analicemos el payload del paquete que genero la alerta del shellcode:

Vemos que al tener NOPS o instrucciones nulas, el ataque ha sido por un desbordamiento de buffer, y a continuación se ha ejecutado una serie de órdenes. Analizando las órdenes vemos que el presunto atacante ha añadido en el initd un servicio TCP que escucha en el puerto 4545, el cual nos proporciona una shell. Posteriormente ha reiniciado el servicio inetd y por tanto ha levantado la puerta trasera.

Ya tenemos una traza de red de lo ocurrido: las imágenes de las particiones del sistema, por lo que vamos a comenzar a obtener los datos preliminares previos al análisis forense.

1º) El ataque fue realizado a las 23:11 del 7 de noviembre de 2000. Los puertos vulnerables parecen ser el RPC. Apuntar puerto 23 y 4545 para estudio visto en la traza de Snort.

2º) En la web de la honeynet nos indica que el timezone del equipo es GMT-06 (CST):

3º) Únicamente se nos proporciona las particiones por lo que hemos perdidos la imagen completa, y por tanto carecemos de dos puntos: el MBR y el HPA. El primero nos proporciona información del arranque de las particiones, el segundo, en caso de existir podría disponer de información escondida por el posible atacante. Teniendo en cuenta que es un reto, damos por sentado que el disco no tenia HPA y el MBR carecia de información relevante.

4º) En la web nos indica que la distribución es una RedHat 6.2. Es importante buscar posibles vulnerabilidades de la distribución durante el 1999-2000 relacionada con el servicio RPC.

5º) Carecemos de cualquier dato volátil del servidor (memoria, uptime, lsof, uname, fdisk, modprobe, etc.).

6º) Necesitamos conocer el sistema de ficheros empleado por el servidor. Por ello para cada partición ejecutaremos la orden “fsstat imagen”, por ejemplo para hda:

Con esto obtenemos información interesante:

• El sistema de ficheros es Ext2 (File System Type: Ext2)
• La última vez que fue montada o se escribio en la partición (lo apuntamos)
• El tamaño del bloque 1024 bytes (Block Size: 1024)

Una vez sabemos que el sistema de ficheros es Ext2 es necesario entender el funcionamiento de este (a leer en google toca). Para el reto nos interesa conocer dos cosas: por un lado el funcionamiento de los “macb” y por otro lado el comportamiento del sistema de ficheros cuando se borra un fichero.

Para ver el comportamiento del sistema de ficheros, y por tanto el macb, podemos buscar las tablas por internet o crearnos nosotros las tablas a mano. En mi caso he decidido crear las tablas a mano. El truco es una vez obtenemos las tablas de un sistema de ficheros lo apuntamos y así no será necesario crear de nuevo la tabla para ese sistema de ficheros. Lo normal es tener tablas para Ext2/3/4, Reiserfs, Fat32, ExtFAT, NTFS, HFS+ y UFS. En nuestro caso vamos a obtener la del Ext2, que es la que nos interesa para el reto.

Las acciones que debemos apuntar son: creación, mover, modificar metadato, modificar dato, copiar y eliminar. Recordar que la “m” del macb apunta a modificación de datos mientras que la “c” apunta a la modificación de la metainformación. En caso de Ext2 la “b” de creación no se emplea (no así en otros sistemas de ficheros como NTFS).

Construiremos una imagen raw con un tamaño de bloque idéntico al obtenido con anterioridad (1024 bytes). Cuidado que el tamaño de bloque estándar es 512 bytes. Una vez creado la imagen la formateamos con el sistema de ficheros que nos interesa y posteriormente montaremos la imagen en modo escritura, haremos la acción que nos interesa, la desmontaremos y veremos que ha cambiado. Los pasos para ello son los siguientes:

Creamos la imagen (una sola vez):

Formateamos la imagen (una sola vez):

El siguiente paso será crearnos un directorio donde montar la imagen (una sola vez):

Los siguientes pasos son repetitivos por cada acción a realizar:

Por ejemplo para la creación de fichero:

Como vemos el fichero prueba tiene asignado el inodo 12 y los tiempos de modificación han sido MAC (File Modified, Accessed y Inode Modified). Lo apuntamos en la tabla. Veamos otro ejemplo, en este caso la copia de ficheros:

Cuando copiamos un fichero, el original modifica su tiempo de acceso y el destino toma en los tres campos la fecha de la copia. Realizando esto obtenemos la siguiente tabla:

• Creación: mac
• Modificación metadato: –c
• Modificación dato: m-c
• Copia(Origen/destino): -a-/mac
• Mover en misma particion: –c
• Mover a otra particion(Origen): -ac(Not Allocated)
• Eliminar(Origen/destino): –c(Not Allocated)

Importante el caso de la eliminación de ficheros, veamos la salida completa de la orden istat cuando eliminamos el fichero prueba2 (inodo 13):

Como vemos, nos indica que el inodo 13 esta libre, quién era su dueño, el tamaño, los tiempos (ifind añade la entrada Deleted al ser un inodo not allocated). Pero lo más importante y diferente a como funciona ext3 o ext4, es que una vez eliminado un fichero, el inodo sigue apuntando al bloque/bloques que contiene la información. Por tanto podemos intentar recuperar la información de forma sencilla, simple claro está, que el bloque no haya sido sobreescrito por otro inodo:

En este caso, la información sigue existiendo, y por tanto hemos podido recuperar un fichero cuya información estaba borrada. Esto es una ventaja frente a ext3/4 donde no podríamos haberlo hecho. Ahora, con los datos ya suministrados podemos comenzar el reto. ¿Te apuntas?