Análisis forense de memoria RAM en Linux

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 realizo 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 sino nos era imposible montar la imagen. Esto ha modificado valores en la imagen y no es validad para realizar el análisis forense de ésta, pero nos sirve para acceder a la información que buscamos. Esto debe de ser una medida para intentar borrar huellas y aumentar la dificultad del reto, pero esto 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 ya que el perfil es una Debian 5.07 con kernel 2.6.26-2-686. Veamos que 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 quisieramos 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 tiene ¿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 esto tenemos la base de por donde comenzar con el reto, que toda sea dicho termina el día 30 de Marzo, queda casi un mes para que finalice. ¡¿A que esperas para apuntarte?!