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

Buenas,

He estado hace poco trasteando un poco con distintas opciones para la extracción de ficheros de capturas de tráfico de red. Tomé como partida estos dos artículos de SANS, que incluyen listados de herramientas, y quiero compartir con vosotros algunos ejemplos de utilización que podrían seros de utilidad. Son 5 métodos de entre muchos posibles, dos son gráficos, dos son de línea de comandos y el último combina ambos.

He tratado de desarrollar un poco más los textos originales a través de un ejemplo práctico, en este caso, capturando en mi dispositivo móvil el tráfico resultante de instalar una aplicación desde el Android Market. He escogido intencionadamente este ejemplo para hablar sobre captura de tráfico en dispositivos móviles, y el hecho de escoger una aplicación determinada responde únicamente a tomar alguna que quizás nos sirva de ejemplo en futuros artículos. La aplicación en sí es IMO Instant Messenger, uno de tantos clientes que permiten conexión a diversas redes y servicios, como Facebook Chat, Google Talk, Skype, MSN, ICQ/AIM, Yahoo, Jabber, Myspace, Vkontakte.ru y la holandesa Hyves, aunque repito que cualquier otra podría haber servido igualmente.

Para capturar el tráfico he empleado Shark, adaptación del popular Wireshark para Android, que permite capturar el tráfico del dispositivo tanto en modo independiente como operando en tethering, soportando 3G y WiFi. La única pega es que requiere root, con lo que caso de instalarlo, os aconsejo que lo hagáis en un dispositivo de pruebas o que eliminéis los binarios su después de las pruebas. Ya sabéis que soy contrario a tener teléfonos corriendo sistemas operativos con privilegios de super usuario circulando por las calles :)

Sea como fuere, estos métodos funcionan independientemente del origen de la captura de tráfico. Da igual si el tráfico procede de un teléfono Android o de un PC de sobremesa, ya que los ficheros de captura resultantes de una adquisición deben respetar la misma estructura para asegurar la interoperabilidad.

Método 1: Network Miner

El más rápido y visual de todos, y el más indicado para personas que no quieren complicarse la vida. Empleando Network Miner esta tarea es prácticamente inmediata y apenas requiere explicación. La captura es auto explicativa :)

pcap network forensics

El resultado es un paquete que puede ser abierto con cualquier gestor de ficheros comprimidos y en cuyo interior encontraremos la estructura básica de un paquete de instalación APK de Android:

pcap network forensics

Método 2: Wireshark

Tratándose de una captura pcap, parece que tiene sentido trata de efectuar la extracción empleando Wireshark. Al ser un entorno gráfico, la operación es igualmente sencilla y prácticamente también se explica sola. Para ello, localizamos la petición GET Market/Binary, efectuamos sobre ella un Follow TCP Stream y salvamos en formato RAW la totalidad de la conversación entre servidor y cliente:

pcap network forensics

El resultado vuelve a ser un fichero que podemos abrir con cualquier gestor de compresión, al igual que en el ejemplo anterior.

Método 3. Extracción mediante tcptrace

Entramos en las modalidades de la línea de mandatos, y empezamos por tcptrace, una interesante aplicación que aunque lleva desde 2004 en estado vegetativo, posee binarios plenamente funcionales que pueden ser utilizados. El comando a emplear es el siguiente:

tcptrace -e fichero.pcap

Una vez ejecutado el programa observamos los patrones de tráfico y seleccionamos la porción que nos interese:

pcap network forensics

En concreto la línea que nos interesa especifica lo siguiente:

14: android_4af33226b2d182ff:39450 – 74.125.15.178:80 (aa2ab)

Luego si aa2ab es el tráfico entre el dispositivo y el servidor, necesitamos el fichero ab2aa, que contendrá el tráfico entre servidor y dispositivo. Intentamos abrir con el gestor de compresión, al igual que hicimos en los ejemplos anteriores, pero se presenta un error. El tipo de archivo no está soportado:

pcap network forensics

¿Y por qué pasa esto? ¿Por qué no podemos obtener limpiamente el fichero APK tras volcar los datos entre servidor y cliente? Examinamos cabeceras

pcap network forensics

Resulta obvio que mientras en el primer caso tenemos al inicio de la cabecera los valores PK, correspondientes al formato de compresión, en el segundo tenemos lo que aparentemente es una petición HTTP. Comprobamos en el editor hexadecimal:

pcap network forensics

De este examen se deduce que los primeros 436 bytes (offsets 0 a 435) del fichero no pertenecen al fichero que pretendemos extraer en sí. El fichero en sí (estructura PK) da comienzo justo en el offset 436. Existen numerosas maneras para eliminar el sobrante, desde el mismo editor hexadecimal si queremos hacerlo de un modo gráfico, o empleando la consola. En este caso escogemos consola, y de paso ilustramos cómo hacer el corte con dd. El comando a ejecutar es:

dd if=ab2aa_contents.dat bs=436 skip=1 of=cortado.dat

pcap network forensics

En este caso hemos empleado el artificio del tamaño de bloque (block size, bs) para decirle a dd que tenemos un tamaño de bloque de 436 bytes, y que queremos que omita completamente el primer bloque (skip=1) siendo el fichero de entrada ab2aa_contents.dat y el de salida cortado.dat. Como no podía ser de otro modo, ahora si es factible desempaquetar nuestra aplicación:

pcap network forensics

Método 4. Extracción mediante tcpick

Método similar al anterior. En este caso empleamos tcpick, que lleva sin desarrollo activo desde 2005 aunque los binarios son sumamente estables y completos.

El comando a lanzar es:

tcpick -wRC -r fichero.pcap

pcap network forensics

El procedimiento de extracción es exactamente el mismo que hemos visto para el caso de tcptrace, incluyendo la necesidad de eliminar el exceso de los primeros 436 bytes, por lo que no lo repetiremos.

Método 5. Extracción mediante chaosreader

El quinto y último método que veremos implica el uso de chaosreader. Es un script Perl que genera ficheros de datos a partir del tráfico junto a un informe HTML sobre la actividad. El comando a utilizar es:

perl chaosreader0.94 fichero.pcap

Una vez generados los ficheros, abrimos el fichero index.html generado por la herramienta:

pcap network forensics

El fichero session_0019.part_01.zip se puede descargar directamente y no precisa de correcciones en la cabecera.

pcap network forensics

Como habéis visto, distintas maneras de obtener el mismo resultado. Algunos métodos son más didácticos que otros, pero al final de lo que se trata es de ser productivos, con lo que cada cual escoja el que más le plazca. Y si alguien quiere comentar algún otro método, que deje un comentario :)

Un saludo,

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

Buenas,

Hacia tiempo que tenia ganas de escribir sobre análisis forense de memoria un poco más en profundidad de lo que he publicado en otras ocasiones, así que aprovechando un rato libre os presento este caso práctico.

Requisitos

  • Instalación funcional de Volatility 2.0. Se aconseja seguir las instrucciones disponibles en http://code.google.com/p/volatility/wiki/FullInstallation
  • Una captura de memoria (en este caso, de una plataforma Microsoft Windows). En este ejemplo se trata del fichero memoria-shernando.mem
  • Posibilidad de ejecutar scripts bash, con lo que se aconseja instalar Volatility en Linux, aunque esto es perfectamente realizable en Windows, y siempre te puedes hacer tus scripts en cualquier otro lenguaje
  • Lectura pausada de los comandos principales de Volatility

Identificando la captura de memoria

Volatility tiene tres comandos asociados a la identificación de volcados de memoria: imageinfo, kdbgscan y kprcscan. Nosotros vamos a usar imageinfo como punto de partida. En esta fase pretendemos confirmar cual es el perfil recomendado para el análisis (Suggested Profile). En primera instancia, el comando imageinfo efectuara una búsqueda basada en estructuras de depuración del núcleo (KDBG) para determinar el perfil, aunque es igualmente posible identificar el sistema examinando los valores de Kernel Processor Control Region (KPCR). El núcleo de Windows emplea KPCR para almacenar información de cada procesador, y se puede localizar en la dirección de memoria virtual 0xffdff000 (ver captura), siendo otra fuente más para identificar el sistema.

python vol.py -f /home/shernando/memoria-shernando.mem imageinfo

volatility forensics

Tomamos nota de los perfiles sugeridos, y escogemos el que nos parezca más adecuado. En este caso, WinXPSP3x86, un XP Service Pack 3 corriendo en una arquitectura convencional de 32 bits con 4 procesadores.

Se pueden consultar los perfiles KDBG y KPCR mediante los siguientes comandos:

python vol.py -f /home/shernando/memoria-shernando.mem kdbgscan

python vol.py -f /home/shernando/memoria-shernando.mem kpcrscan

Enumeración de procesos en ejecución

Quizás lo mas inmediato y típico al evaluar una imagen de memoria sea conocer que procesos estaban en ejecución en el momento de efectuar la captura. Emplearemos pslist especificando el perfil que hayamos identificado en el paso anterior:

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem pslist

Para cada proceso se obtiene un offset de memoria, el nombre del proceso, el identificador de proceso (PID) y el identificador del proceso del proceso padre (PPID), el número de hilos, número de handles y fecha/hora en la que el proceso se inició. El offset que se obtiene por defecto es el virtual, si se quiere obtener el offset físico hay que emplear el operador -P, tal y como se explica en la documentación de Volatility. La información se presenta de una manera legible:

volatility forensics

Para ilustrar nuestro ejemplo seleccionamos, dentro de la lista de procesos, el correspondiente a la ejecución de Mozilla Firefox. Escogemos este ejemplo ya que en los navegadores es frecuente que exista uso de contraseñas, con lo que trataremos de localizar alguna en la memoria para ilustrar las capacidades de Volatility.

volatility forensics

En este caso, el navegador se ejecuta con PID 4128, con PID padre 1668 (algo normal, ya que pende de explorer.exe)

volatility forensics

Para quien esté interesado, el comando pstree muestra los procesos ordenados en árbol, con lo que es fácil deducir las dependencias para cada caso. El comando a ejecutar sería:

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem pstree

volatility forensics

A modo de ejemplo, en este caso se observa como services.exe pende de winlogon.exe y smss.exe, lo que viene siendo algo normal en una plataforma Windows. Como es lógico, la gestión de servicios (services.exe) depende del gestor de sesiones, que a su vez pende del subsistema de gestión de sesiones (smss.exe). Todos pertenecen al grupo de procesos SYSTEM. En rojo, las relaciones entre PIDs padre e hijo a título informativo.

Volcado específico del proceso en estudio (Método 1: memdump)

Con este método podemos aislar la porción de memoria en uso para un proceso determinado. Esto facilita las cosas, ya que en equipos modernos las imágenes de memoria (coincidentes con la memoria física instalada) pueden alcanzar 4, 6 u 8 GB con facilidad. Cuanto mas acotemos, menos trabajo de inspección sera necesario. No olvidemos que examinar cadenas de texto en una imagen de memoria es un ejercicio que no tiene por que traer resultados satisfactorios de vuelta, de modo que cuanto más facilitemos la labor, mejor.

Afortunadamente, memdump permite realizar el volcado de todos los segmentos de memoria asociados a un proceso. Nótese que por la dependencia de procesos en un sistema operativo, esto acarreara que además de los segmentos propios de un proceso se vuelquen todos los que por una razón u otra pudieran estar en uso como consecuencia de las dependencias entre procesos. No obstante, el tamaño de dicho volcado sera normalmente menor. Para este ejemplo, de un total de 3 GB de memoria, la ejecución sobre el PID de Firefox en estudio originó un volcado de 550.8 MB.

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 memdump -D volcados

Una vez obtenido el volcado, extraemos las cadenas de texto para ser inspeccionadas. A pesar de la reducción por focalización nos enfrentamos a 30.7 MB de fichero de texto como resultado.

strings volcados/4128.dmp >> volcados/4128.dmp.txt

Un simple grep sobre la cadena Passwd servirá para localizar las credenciales que buscábamos:

cat volcados/4128.dmp.txt | grep Passwd

volatility forensics

Volcado especifico del proceso en estudio (Método 2: Análisis del árbol VAD)

En el trabajo forense de imágenes de memoria de plataformas Windows es posible trabajar con el árbol de descriptores de direcciones virtuales (Virtual Address Descriptor, VAD). La idea es la siguiente: habida cuenta que las estructuras VAD proporcionan una abstracción a mas bajo nivel de la memoria, es posible emplearlas para realizar un análisis más enfocado. Técnicamente, el árbol VAD establece las relaciones de los distintos rangos de memoria empleados por un proceso determinado. A medida que el mecanismo de asignación VirtualAlloc asigna memoria en un proceso determinado, se van añadiendo entradas al arbol VAD, de modo que si obtenemos la estructura del árbol para un proceso, obtendremos todos los rangos de memoria en uso para dicho proceso.

Para trabajar con VADs, Volatility ofrece 4 comandos: vadwalk, que ofrece una visión general del árbol VAD, vadtree que muestra la información en forma de árbol propiamente dicho, vadinfo , que arroja información extendida de los nodos VAD y vaddump, que permite realizar volcados de la estructura VAD. En su mayoría admiten discriminación por PID. Los comandos a ejecutar, serian para cada caso, los siguientes:

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 vadwalk

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 vadtree

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 vadinfo

Para ilustrar nuestro ejemplo utilizaremos vaddump:

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 vaddump -D vads

Esta ejecución salvará, en el directorio vads, los distintos segmentos asociados al proceso. Aquí dejo un extracto del resultado, que en este caso contiene 346 elementos que totalizan 285.1 MB.

volatility forensics

Habida cuenta que extraer cadenas de 346 elementos es inviable si se hace a mano, podemos escribir un pequeño script que automatice la extracción para nosotros:

#!/bin/sh

for filename in /home/sansforensics/volatility-2.0/vads/*
do
  	echo "Processing" $filename >> results.txt
  	echo >> results.txt
	strings $filename >> results.txt
  	echo ------------------------------------------- >> results.txt
done;

Este script producirá un fichero consolidado results.txt, en este caso de 5.4 MB. Al igual que antes, la búsqueda de la cadena Passwd arroja, como no podía ser de otro modo, idénticos resultados. Esto es totalmente normal y esperado, ya que a fin de cuentas hemos inspeccionado las mismas porciones de memoria, con dos métodos distintos.

volatility forensics

Graficando el árbol VAD

El comando vadtree permite la obtención de un fichero en formato Graphviz para el proceso en estudio. Con ayuda de kgraphviewer o cualquier programa similar, es posible visualizar el árbol VAD generado.

python vol.py –profile=WinXPSP3x86 -f /home/shernando/memoria-shernando.mem -p 4128 vadtree –output=dot –output-file=graficovad.dot

Si alguien tiene curiosidad, he dejado el fichero resultante aquí. También para curiosos, una impresión del gráfico en PDF generada con kgraphviewer. Dada la gran cantidad de nodos, y con la idea de mantener un tamaño PDF reducido, la resolución es pequeña, aunque sirve para hacerse una idea.

BONUS

Ademas de lo que hemos explicado, Volatility puede hacer muchas más cosas. Merece la pena probar sus funcionalidades. Os dejo un vídeo reciente sobre una de las muchas cosas que podéis hacer: Cracking Passwords with Volatility and John: Now With 34.3% Better Video!

Un saludo,