Análisis forense de memoria en sistemas UNIX

Hola,

Siguiendo en la línea sobre análisis forense de memoria en sistemas Windows, a la que hemos dedicado dos artículos recientemente, toca ahora hablar sobre la inspección de memoria en sistemas UNIX y derivados.

En el mundo UNIX existen infinidad de herramientas y métodos para el análisis forense, y nos podría llevar mucho tiempo realizar un estudio completo sobre todas las posibilidades, con lo que enfocaremos el artículo única y exclusivamente a una extracción práctica de determinada información de una memoria RAM.

/dev/mem y /proc/kcore

En nuestros artículos anteriores hemos visto como es posible acceder, en sistemas Windows, a un dispositivo virtual que se llama .PhysicalMemory, y obtener de él un volcado de la memoria física del sistema.

En sistemas derivados de UNIX, los dispositivos equivalentes son /dev/mem y /dev/kmem, siendo lo normal acceder a los contenidos de la RAM a través del fichero /proc/kcore si hablamos de Linux. Este tipo de ficheros tiene como principal ventaja la utilización del formato de core ELF, lo que permite su depuración con herramientas UNIX estándar como gdb.

Realizar un volcado de la memoria a través de /proc/kcore

La manera más rápida de ejecutar el volcado es mediante dd:

dd if=/proc/kcore of=/ruta/de/la/imagen.dd

En nuestro ejemplo, el volcado contiene 2072568+0 registros de entrada, 2072568+0 registros de salida y un tamaño de 1061154816 bytes (1,1 GB). El proceso ha requerido 18,3771 segundos, siendo por tanto la tasa de transferencia de aproximadamente 57,7 MB/s.

Realizar un volcado de la memoria a través de /dev/mem

Empleamos dd nuevamente:

dd if=/dev/mem of=/ruta/de/la/imagen.dd

Analizando el volcado. Extracción de strings

Puede parecer simple y rudo, pero es un método efectivo. En vez de deternenos a encontrar procesos en ejecución, tal y como hemos hecho en otras entregas, o hablar de herramientas específicas para analizar volcados, vamos a poner algunos ejemplos prácticos sobre el tipo de información que puede residir en la memoria, y para ello la manera más fácil es buscar cadenas directamente en el volcado, por simple que parezca.

strings –a –t x /ruta/de/la/imagen.dd

Si nos llevamos a fichero el resultado en nuestro ejemplo real, tenemos un fichero de unos 455 MB repleto de cadenas, lo que puede ser inviable para su barrido línea a línea, pero útil si queremos localizar cadenas determinadas. Algunos ejemplos podrían ser los siguientes:

Detalle de la clave de root en un servidor MySQL resultado de autenticación vía línea de comandos – Linux Ubuntu 8.04

72c58e7 mysql -u root -pCLAVE
72c58ff mysql -uroot -pCLAVE
72c5916 mysql -uroot -pCLAVE
72c592d mysql -uroot -pCLAVE
72c5944 mysql -uroot -pCLAVE

Detalle de la clave de un proxy http exportada en un perfil bash – Linux Ubuntu 8.04

561d248 export http_proxy=»http://USUARIO:CLAVE@DIRECCION.PROXY:8080/»

Detalle de /etc/master.passwd (incluye las claves cifradas de root y usuario shernando) – FreeBSD 7.0

1800404c root:$1$5OkS4l/j$tpVGEXsowA4iAi4wUF2tA1:0:0::0:0:Charlie &:/root:/bin/csh
18004096 toor:*:0:0::0:0:Bourne-again Superuser:/root:
180040c4 daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
1800410d operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
1800413e bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
1800417e tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
180041b1 kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
180041e6 games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
18004227 news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
1800425a man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
1800429b sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
180042de smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
18004334 mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
18004384 bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
180043b7 proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
18004403 _pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
18004449 _dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
18004487 uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
180044df pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
18004520 www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
18004565 nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin
180045b0 cyrus:*:60:60::1214344800:0:the cyrus mail server:/nonexistent:/usr/sbin/nologin
18004601 cups:*:193:193::0:0:CUPS Owner:/nonexistent:/usr/sbin/nologin
1800463f shernando:$1$xVZHX9KU$9UWRZ8TJW1kmU9v0n9.Mr1:1001:1001::0:0:Sergio Hernando:/home/shernando:/bin/sh

Detalle de accesos de usuario root – FreeBSD 7.0

1880f0ef Jun 25 22:16:51 nas login: ROOT LOGIN (root) ON ttyv0
1880f1da Jun 25 22:43:51 nas login: ROOT LOGIN (root) ON ttyv0
1880f3fd Jun 25 23:21:25 nas login: ROOT LOGIN (root) ON ttyv0
1880f4e8 Jun 28 21:26:21 nas login: ROOT LOGIN (root) ON ttyv0
1880f5d3 Nov 2 19:33:37 nas login: ROOT LOGIN (root) ON ttyv0
1880f63b Nov 2 19:38:58 nas login: ROOT LOGIN (root) ON ttyv0
1880f726 Nov 2 19:41:31 nas login: ROOT LOGIN (root) ON ttyv0
1880fab7 Nov 2 21:41:28 nas login: ROOT LOGIN (root) ON ttyv0
1880fd32 Nov 2 22:15:20 nas login: ROOT LOGIN (root) ON ttyv0

Dos accesos SSH de los usuarios root y shernando (autenticados vía teclado) con IPs de origen – FreeBSD 7.0

1880fe5c Nov 2 23:01:19 nas sshd[985]: Accepted keyboard-interactive/pam for root from 192.168.1.250 port 2253 ssh2
1880fec8 Nov 2 23:06:16 nas sshd[1010]: Accepted keyboard-interactive/pam for shernando from 192.168.1.250 port 2256 ssh2

El usuario shernando tiene un perfil mldonkey en su home (FreeBSD 7.0)

18d2cfe2 /usr/home/shernando/.mldonkey

Y lo utiliza (FreeBSD 7.0)

ef61099 7:55.09 /usr/local/bin/mlnet-real

Configuración de red del servidor (FreeBSD 7.0)

14370121 defaultrouter=»192.168.213.1″
1437014e ifconfig_rl0=»inet 192.168.213.254 netmask 255.255.255.0″

Identificación de un mensaje de correo saliente con ID de mensaje – FreeBSD 7.0

1ad73180 sm-mta[7553]: mBAJBFVw007553: from=sergio@sahw.com, size=712, class=0, nrcpts=1, msgid=<200812101911.mBAJBFVw007553@nas>, proto=SMTP, daemon=Daemon0, relay=localhost [127.0.0.1]

El volcado de memoria puede servir para muchas más cosas, y estos son sólo algunos ejemplos. De hecho, los volcados más tradicionales en el mundo UNIX son provocados no por técnicas forenses, sino para efectos de depuración (análisis de crashes, de core dumps, crash forzado, etc), aunque como es obvio, resultan útiles en procesos de investigación, ya que pueden proporcionar pistas para los investigadores.

Recordad que el complemento perfecto al análisis forense en vivo es el análisis post-mortem, siempre que sea posible, extrayendo imágenes de los discos que pueden ser analizadas con tranquilidad en el laboratorio. La información volátil es útil, pero la persistente suele ser siempre más jugosa :)

Un saludo,

Análisis forense de memoria en sistemas Windows

Hola,

Vamos a ver un ejemplo muy sencillo sobre cómo ejecutar una inspección forense de la memoria de un sistema Windows.

Para ello vamos a necesitar dos herramientas: Mantech Memory DD y Volatility, sobre el cual ya hablamos en este blog. Sobre la elección de ambas herramientas es principalmente porque son libres y gratuitas, con lo que experimentar no tendrá coste para nosotros.

El análisis forense de volcados de memoria cobra especial importancia en eventos de respuesta ante incidentes, ya que permite obtener una foto de cómo se encuentra la RAM, así como para obtener información relevante para los análisis de máquinas donde se desea saber el estado de la memoria antes de proceder a su apagado. La RAM es volátil, y si pulsamos off, nos quedamos sin información.

Extracción de un volcado de memoria

Tal y como hemos comentado, emplearemos una utilidad que se llama MDD. La sintaxis básica es la siguiente:

mdd_1.3.exe -o nombredelvolcado

Así, por ejemplo:

mdd

En este proceso hemos obtenido un fichero que se llama volcadomemoria.img, cuyo MD5 (importante para preservar la integridad de la evidencia) es cf1d38ca7dbf0ab7f1444df158cc7150 y que ha resultado exitosa para 258009 operaciones de mapeo, siendo infructuosa en 3634 operaciones. El tamaño resultante es de 1.071.689.728 bytes.

Análisis del volcado

Nos apoyaremos en Volatility. Este framework permite el análisis de volcados de memoria y es mutiplataforma (siempre y cuando tengamos Python instalado)

Es bastante fácil de usar. Así, por ejemplo, si deseamos conocer los procesos que estaban ejecutándose en memoria, emplearemos

$ python volatility pslist -f nombredelvolcado

En nuestro caso:

volatility

No muestro la totalidad de los procesos de una manera intencionada. En este ejemplo vemos los procesos smss.exe (gestor de sesiones de Windows), csrss.exe (client server runtime), winlogon.exe (aplicación de logon de Windows), services.exe (servicios y controlador) y lsass.exe (ejecutable LSA Windows)

Volatility permite lanzar muchas consultas interesantes desde el punto de vista forense. Veamos algunos ejemplos

Obtención de propiedades de la imagen

$ python volatility ident -f volcadomemoria.img
Image Name: volcadomemoria.img
Image Type: XP SP2
VM Type: pae
DTB: 0x73a000
Datetime: Tue Dec 02 22:19:29 2008

Fecha y hora del volcado

Aunque es parte de la consulta anterior, se puede invocar de modo independiente

$ python volatility datetime -f volcadomemoria.img
Image local date and time: Tue Dec 02 22:19:29 2008

Módulos cargados en el sistema

volatility

La lista es, obviamente, mucho más larga. Está truncada intencionadamente.

Objetos EPROCESS

volatility

En este ejemplo vemos un proceso correspondiente a la utilidad Blowfish Advanced CS (bfacs.exe), una utilidad que os recomiendo para cifrar información personal en vuestros discos.

Ficheros abiertos por cada proceso

Esta consulta es muy intensa, pero es extremadamente útil. Mostramos un ejemplo:

************************************************************************
Pid: 1036
File \WINDOWS\system32
File \WINDOWS\system32\ega.cpi
************************************************************************

Y para identificar ese PID recurrimos a la lista de procesos:

$ python volatility pslist -f volcadomemoria.img | grep 1036
csrss.exe 1036 960 13 704 Tue Dec 02 18:24:06 2008

De donde se deduce que el proceso csrss.exe está empleando el fichero fichero de codificación (codepage information file) \WINDOWS\system32\ega.cpi

En cuanto a aplicaciones convencionales:

************************************************************************
Pid: 4008
File \Archivos de programa\Mozilla Firefox
File \Documents and Settings\sergioadmin\Application Data\Mozilla\Firefox\Profiles\12hgbwhw.default\parent.lock

De donde se deduce que el usuario ejecutaba Firefox, con PID 4008, y empleando el perfil 12hgbwhw.default (el cual podremos inspeccionar con la imagen del disco duro que levantemos en el escenario).

Volatility tiene muchas más funciones, y estas tan sólo son algunas. La idea es mostrar cómo se adquiere un volcado de memoria, el tipo de información que puede almacenar, cómo se lanza un procesado básico, así como la importancia de levantar este tipo de información siempre que sea posible.

Espero que el texto os resulte de utilidad.

Un saludo,