Análisis forense de memoria RAM en Linux

(N.d.E. Hemos tenido algunos problemillas esta mañana con el blog. Esperamos que todo haya vuelto ya a la normalidad)

Durante el inicio de un incidente, el grupo encargado de su gestión debe comprobar primeramente si el incidente ha ocurrido. En caso afirmativo el primer paso a realizar sobre él o los entornos afectados es el volcado de la memoria RAM, puesto que es la pieza más crítica al ser la parte más volátil, y por ello, la que más fácilmente puede ser alterada durante el incidente.

Para ello se suelen emplear tanto herramientas libres como privadas, principalmente winXXdd o memoryze para entornos Windows y Memdump para entornos Linux. Esa captura debe ser copiada a otro entorno y nunca en el sistema de ficheros del entorno afectado, para ello se puede emplear NetCat (nc) o Samba (CIFS).

Pero es el análisis posterior donde radica la dificultad. Debemos de ser capaces, de dado el fichero en crudo de la memoria RAM, poder obtener información importante como qué programas se estaban ejecutando, qué puertos escuchando, qué ficheros abiertos, qué usuarios conectados, qué rutas ARP, qué configuración de las interfaces de red, etc.

En caso de tratarse de entornos Windows existen varias herramientas como Memparser para Windows 2000, Volatility para Windows XP SP2 y 3, o la herramienta por excelencia que consiste en la combinación de la captura de la memoria mediante Mandiant Memoryze y su posterior análisis con Audit Viewer.

Por desgracia en entornos Linux se carecía de cualquier tipo de herramienta que nos permitiera obtener esta información. Habían pequeños proyectos pero no terminaban de cuajar. Pero recientemente tuve el placer de leer una entrada en un blog donde se informaba que la herramienta Volatility, cuya última versión era del 2008, había sido retomada de nuevo, y entra las nuevas mejoras, se encontraba el soporte a una serie de entornos Linux.

Junto con dicha entrada del 1 de Marzo, coincidió que el proyecto Honeynet sacaba un nuevo reto de análisis forense donde era necesario la gestión de la memoria RAM en un entorno Linux. ¿Un buen lugar donde probar esta nueva herramienta, verdad?

Empecemos instalando dependencias, descargando la herramienta y la captura RAM del reto:

# apt-get install subversion unzip 
# svn checkout http://volatility.googlecode.com/svn/branches/linux-support vollinux 
# cd vollinux 
# wget http://yom.retiaire.org/dl/victoria-v8.memdump.img.zip 
# unzip victoria-v8.memdump.img.zip 
# chmod ug+x *.py

Para usar la nueva versión de Volatiliy (1.4_rc1 en nuestro caso) es necesario indicarle el perfil de la captura, es decir, la distribución y el kernel usado por el equipo donde se realizó el volcado de la memoria. Para ello es necesario descargarse la captura RAW de la partición del reto y obtener esta información:

# wget http://yom.retiaire.org/dl/victoria-v8.sda1.img.zip 
# unzip victoria-v8.sda1.img.zip 
# mkdir tmp 
# fsstat victoria-v8.sda1.img | grep -i "file system type" 
File System Type: Ext3 
# mount -t ext3 -o loop,noatime victoria-v8.sda1.img tmp/ 
# umount tmp/ 
# mount -t ext3 -o loop,ro,noatime victoria-v8.sda1.img tmp/

Sí, hemos tenido que montar en modo escritura la primera vez porque si no nos era imposible montar la imagen, lo que ha modificado valores en la imagen y no es válida para realizar el análisis forense de ésta, pero nos sirve para acceder a la información que buscamos. Esto debe ser una medida para intentar borrar huellas y aumentar la dificultad del reto, pero ya lo trataremos en otra entrada. Obtengamos la información requerida:

# ls tmp/boot/ 
config-2.6.26-2-686  grub  initrd.img-2.6.26-2-686  System.map-2.6.26-2-686  
vmlinuz-2.6.26-2-686 
# cat tmp/etc/debian_version 
5.0.7 
# cat tmp/etc/apt/sources.list | grep lenny 
... 
deb http://ftp.fr.debian.org/debian/ lenny main 
# umount tmp/

Con esto sabemos que el perfil requerido es una Debian 5.07 con kernel 2.6.26-2-686. Veamos qué perfil se adapta a esta configuración:

# python volatility.py --info 
... 
PROFILES 
-------- 
... 
debian2626        - A Profile for debian 2.6.26-2-686 
.. 

El perfil que nos interesa es “debian2626”. Ya podemos usar la nueva herramienta mediante la siguiente sintaxis:

# python volatility.py -f <imagen> --profile=<perfil> <plugin>

Con ello si quisiéramos obtener que puertos estaban a la escucha en el equipo sería mediante el plugin “linux_netstat”:

# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_netstat 
Volatile Systems Volatility Framework 1.4_rc1 
UDP      0.0.0.0:111   0.0.0.0:0                portmap/1429 
TCP      0.0.0.0:111   0.0.0.0:0     LISTEN           portmap/1429 
UDP      0.0.0.0:769   0.0.0.0:0              rpc.statd/1441 
... 
UDP      0.0.0.0:68    0.0.0.0:0              dhclient3/1624 
... 
TCP      0.0.0.0:25    0.0.0.0:0     LISTEN             exim4/1942 
TCP      192.168.56.102:43327 192.168.56.1:4444  ESTABLISHED                sh/2065 
TCP      192.168.56.102:43327 192.168.56.1:4444  ESTABLISHED                sh/2065 
... 
TCP      192.168.56.102:56955 192.168.56.1:8888  ESTABLISHED                nc/2169

Ups, ese netcat en el puerto 8888 y esos sh en el puerto 4444 que mala pinta tienen, ¿verdad?

Otros plugins interesantes son los siguientes:

• linux_list_open_files: permite obtener el listado de ficheros.
• linux_task_list_ps: procesos en ejecución.
• linux_lsmod: muestra los módulos del núcleo cargados.
• linux_mount: las particiones montadas en el entorno.
• linux_ifconfig: configuración de las interfaces de red.
• linux_route: tabla de enrutamiento.
• linux_arp: tablas arp.

Por tanto, con ejecutar las siguientes ordenes tendríamos respuesta a muchas de las preguntas del reto:

# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_list_open_files 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_task_list_ps 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_lsmod 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_mount 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_netstat 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_ifconfig 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_route 
# python volatility.py -f victoria-v8.memdump.img --profile=debian2626 linux_arp 

Con esta información tenemos la base de por dónde comenzar con el reto, que todo sea dicho termina el día 30 de Marzo, por lo que queda casi un mes para que finalice. ¡¿A qué esperas para apuntarte?!