Análisis forense de memoria en sistemas UNIX

Publicada en Por Sergio Hernando

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:[email protected]: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: [email protected], 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,

Entrada relacionada

5 métodos para la extracción forense de ficheros en capturas de tráfico de red

Publicada en

Análisis avanzado de memoria de sistemas Microsoft Windows con Volatility

Publicada en

Análisis forense de Volume Shadow Copy Service (VSCS) mediante herramientas Sleuth Kit

Publicada en

Chrome forensics. Processing the history file with Perl

Publicada en

Using Perl and SQLite in digital forensics: Firefox Download Manager as an example

Publicada en

9 comentarios sobre “Análisis forense de memoria en sistemas UNIX”

  1. Pingback: linuxfera.net

  3. Hola corsaria,

    Lamento que no te enteres, pero bueno, de vez en cuando soy consciente de que se me va la pinza y me meto en barro denso.

    Sobre el advisory que me pones, pues nada, una más de ejecución remota de código en Explorer. Es de caracter extremadamente crítico (yo aconsejaría seriamente no usar IE) porque no sólo permite la ejecución remota de código, sino que además, hay exploits por ahí circulando alegremente, y encima, está sin resolver. Un cóctel letal.

    Hay por ahí un workaround chapucero, consistente en descativar una dll (Oledb32.dll), pero insisto en que el panorama invita a no usar IE hasta que el problema esté corregido.

    Puedes ver más info en

    http://secunia.com/advisories/33089/
    http://www.avertlabs.com/research/blog/index.php/2008/12/09/yet-another-unpatched-drive-by-exploit-found-on-the-web/

    Un saludo, y perdona por la tardanza (he estado unos días fuera)

  5. Que tal gracias por la informacion son buenos tus articulos aunque tuve un pequeño problema al intentar lo que aqui mencionas a ver si me puedes irientar sobre la causa cuando intento leer ya sea /dev/mem o /proc/kcore me indica que la operacion no es permitida y lo estoy ejecutando como root investigando un poco al parecer en nuevos sistemas linux la lectura directa de esos ficheros virtuales ya no esta permitida estoy usando Fedora 6 y digo directa porque al intentar hacerlo desde un programa en c si que me deja acceder en modo lectura

    gracias.

  6. Kros,

    No utilizo Fedora, pero me extraña lo que me comentas. Especialmente el caso de /proc/kcore, ya que el que te deje sin acceso a /dev/mem es relativamente normal.

    ¿Has acudido a los foros de Fedora? Quizás allí te expliquen qué puede estar pasando. Yo sin tener la máquina delante, poco más puedo aportar.

    Un saludo,

  7. Pingback: Análisis forense de teléfonos basados en sistemas Android » Sergio Hernando
  8. Pingback: Análisis forense de teléfonos basados en sistemas Android | Shadow Security

Comentarios cerrados.