Tener la posibilidad de cerrar la tapa del portátil y encontrarnos las cosas como estaban al volver a abrir la tapa es una gran ventaja para muchas personas. Desde la aparición de Windows 2000, el sistema operativo de Redmond soporta una función que casi todos hemos empleado en alguna ocasión: la suspensión de estado a disco, o hibernación.

La hibernación en el nivel de sistema operativo tiene como principal ventaja no requerir drivers adicionales. Técnicamente hablando también es frecuente encontrar en la literatura referencias al estado de hibernación como ACPI S4 (Advanced Configuration and Power Interface). Este estándar abierto, cuya primera versión data de 1996, fue escrito originalmente por Intel, Microsoft, y Toshiba. En síntesis, y para equipos Microsoft, el estado ACPI S4 se traduce, en términos prácticos, en la creación de un fichero oculto llamado hiberfil.sys, cuyo tamaño total es siempre equivalente a la cantidad de RAM de la máquina. La hibernación sólo es posible si todo el hardware de la máquina cumple con los requisitos ACPI y Plug-and-play, debiendo ser los drivers compatibles con PnP.

Este fichero no es más que una imagen de la memoria de la máquina comprimida con un algoritmo que nunca ha sido publicado ... hasta que alguien encontró la manera de manipular estos ficheros.

Accediendo y manipulando ficheros de hibernación. La manera elegante

La manera elegante (y a su vez, adecuada) para analizar ficheros de hibernación es la transformación en volcados forenses que podamos utilizar en nuestras herramientas habituales. La primera referencia sobre cómo realizar esta tarea es obra de Matthieu Suiche, autor en 2008 de una charla BlackHat llamada Windows Hibernation File for Fun and Profit en la que ofreció detalles acerca de cómo manipular este tipo de ficheros. Suiche, como parte de su proceso de investigación, realizó ingeniería inversa y dedujo cómo estaban comprimidos los ficheros hiberfil.sys. También, como parte del proceso de investigación, Suiche liberó las herramientas Sandman para poder manipular los ficheros de hibernación.

Lo que en su día fue Sandman es hoy en día Moonsols Windows Memory Toolkit, que tiene una versión comercial y una versión community que podéis descargar y usar. Dentro del juego de herramientas hay una aplicación llamada hibr2bin que puede ser utilizada para la conversión.

También es posible convertir ficheros de hibernación a una imagen cruda empleando Volatility, que dispone de un módulo llamado hibinfo basado en el código de Suiche. Este módulo permite generar una imagen legible a partir del fichero de hibernación.

Una vez obtenida una imagen lineal, es trivial analizar los contenidos. Ya que hemos hablado de Volatility, ojead este artículo para tomar alguna idea sobre cómo realizar el análisis. También podéis ojear los contenidos de este otro artículo.

Strings en Unix. Una manera rápida de evaluar los contenidos de los ficheros de hibernación.

Si lo que queremos es hacer una evaluación rápida de los posibles contenidos del fichero, sin tener que generar una imagen legible, es posible buscar en los contenidos del fichero una vez extraídas las cadenas.

Estos son algunos ejemplos de los contenidos de mi fichero de hibernación:

Algunos usuarios y servicios de red:

Credenciales de Filezilla:

Administrador de router, contraseña y contraseña wireless:

¿Cómo solucionar el problema?

Aunque la hibernación es una funcionalidad que se puede desactivar, el primer pensamiento que nos puede venir a la mente para protegernos ante la recuperación indeseada del estado de hibernación quizás sea el cifrado completo del disco. Esto, que dicho sobre el papel suena fácil, es en realidad un problema difícil de solucionar. Habida cuenta de que Microsoft no proporciona APIs para manipular el proceso de hibernación, los procesos de cifrado de este fichero se basan (con la excepción de BitLocker, cifrado nativo de Microsoft) en la modificación de componentes de Windows que no están documentados, con lo que ante cualquier cambio por parte del fabricante los medios escogidos para el cifrado podrían tornarse inútiles. La situación de ventaja que tiene BitLocker sobre otros medios es un tema que sigue suscitando polémica, y que sigue sin estar plenamente resuelta.

Un saludo,

Aprovechando que desde hace algún tiempo tengo un Nexus One quiero compartir con vosotros los pasos básicos para poder realizar una auditoría forense de este tipo de dispositivos, con el fin de que comprendáis un poco mejor cómo se organiza el sistema de ficheros en Android y cómo localizar información sensible dentro del mismo. También quiero que este texto sirva para ilustrar que la pérdida o el robo de un teléfono implica que siempre es posible tratar de recuperar datos sensibles de él, y aquí vamos a poner alguos ejemplos.

Describir un procedimiento completo y detallar todas y cada una de las ubicaciones en el sistema donde puede haber información sensible sería largo y costoso. Prefiero hacer una descripción general y poner algunos ejemplos prácticos que espero sean de vuestro agrado y utilidad. Estos ejemplos están enfocados al análisis forense de un sistema de ficheros, con lo que otras partes del sistema como la memoria no están cubiertas. Si te interesa esta última disciplina, quizás te interese este artículo.

Requisitos previos

• Ser root en el sistema, lo cual se logra normalmente desbloqueando el bootloader para proceder a ganar root. Hay infinidad de artículos al respecto en Internet. En la enorme mayoría de los artículos se utliza fastboot para desbloquear el bootloader y superboot para ganar root arrancando una imagen boot.img que permite la ejecución con usuario root. Ganar root implica perder la garantía del teléfono, así que abstente si no tienes absolutamente claro cómo hacerlo.
• La manera natural de intractuar con el teléfono a nivel consola es lanzar comandos mediante Android Debug Bridge (ADB). ADB es parte del SDK de Android y nos permite conectar al dispositivo estando este conectado via USB en la máquina que queramos analizar. Ojito si vais a usar ADB en Windows, ya que tenemos que tener el driver USB instalado (consultar SDK). En cualquiera de los casos, tanto Windows como Mac o Linux, la depuración USB tiene que estar activada en el teléfono.
• De modo altrnativo, es factible tener un servidor SSH instalado en el teléfono. Con paciencia y un poco de conocimiento se puede echar a andar Dropbear. También se pueden emplear ROMs que tengan el demonio SSH incorporado. Por último puedes comprar en el Market una aplicación que habilite un servidor SSH sin complicaciones, como por ejemplo QuickSSHD.

Conectando con el teléfono

En este artículo emplearemos el SDK de Android, que incluye la herramienta Android Debug Bridge (ADB) para conectar al teléfono. En mi caso particular el rendimiento de conectar vía SSH en una red WLAN es muy pequeño a causa de la señal, con lo que prefiero hacerlo con el teléfono conectado con el cable USB, lo que me hará tener mejores cuotas de transferencia al mover ficheros. Es indiferente emplear Windows o Linux, cada cual que escoja lo que más le guste:

Si al solicitar la lista de dispositivos conectados vemos claramente nuestro dispositivo podemos proceder con tranquilidad, ya que todo ha ido correctamente y estamos en condiciones de operar. Caso contrario hemos de referirnos a la documentación. A los que uséis Linux comentaros que pese a que el binario está precompilado y no hay por tanto que compilar (basta con extraer las herramientas del SDK) sí que es preciso crear un fichero de reglas y relanzar udev para que lea los cambios. Si no hacéis estos dos pasos no veréis el dispositivo conectado. Una vez conectado el dispositivo, lanzamos la consola:

Nuestra primera ejecución será un listado del directorio raíz:

El sistema de ficheros Android

Android está basado en un núcleo Linux. Como tal la manera de aproximarse al sistema es la que usaríamos en cualquier derivado de Unix, teniendo en cuenta las particularidades de cada caso.

Un primer vistazo nos revela la composición del sistema de ficheros:

En lo que a dispositivos se refiere se puede observar que los puntos de montaje para /system, /data y /cache están asociados a distintos mtdblocks presentes en /dev/block/. Es también el caso de la tarjeta SD externa que acompaña a este modelo de teléfono, montada en /sdcard.

MTD es un subsistema Linux llamado Memory Technology Devices. En aquellos sistemas Linux donde no existen dispositivos de bloque tradicionales (las unidades de disco, por ejemplo) sino que el sistema está embebido en un medio flash, como es el caso del teléfono, es normal encontrar dentro de los puntos de montaje habituales referencias a los bloques MTD (en nuestro caso, son los mtdblocks).

Para comprender esta nomenclatura basta con pensar en las convenciones que se toman para dispositivos de bloque tradicionales, como por ejemplo los discos IDE (/dev/hd* significando hd hard drive) o los discos SCSI o SATA (/dev/sd*). En este caso es exactamente igual, pero sin embargo existe una diferencia: Los MTD siguen la nomenclatura /dev/mtd*

Podemos obtener más información de los dispositivos inspeccionando /dev y /proc:

En esta última captura podemos ver otro distintivo característico de los dispositivos MTD, y es que en vez de tener sectores como los dispositivos de disco, tienen eraseblocks cuyo tamaño viene definido por erasesize.

Igualmente, del listado de /dev/mt* se puede verificar que cada dispositivo cuenta con un dispositivo ro asociado, así para mtd0 tenemos mtd0ro, etc. En este caso ro implica read only, sólo lectura. Para poder utilizar sistemas de ficheros convencionales en dispositivos MTD es preciso emular dispositivos de bloque sobre el dispositivo MTD. Esta necesidad mana de la propia naturaleza de un MTD, y en el caso de Linux se emplea mtdblock. Cuando se carga este módulo automáticamente se crea un dispositivo de bloque para cada dispositivo MTD presente en el sistema. El acceso a esos dispositivos de bloque se hace a través de los nodos de dispositivo /dev/mtdblock, motivo por el cual aparecen en la ejecución de mount.

Una vez entendido esto es más o menos sencilo realizar una correlación. Así por ejemplo, para realizar una imagen forense del dispositivo boot habrá que emplear mtd2

Para trasladar el fichero al equipo del investigador existen varios métodos. El más cómodo es usar la funcionalidad pull de ADB, aunque aquellos que tengan SSH o un servidor FTP pueden recuperar los ficheros empleando esos protocolos, o incluso montando la tarjeta en un lector de tarjetas.

Una vez tengamos los ficheros en la máquina podemos analizarlos empleando nuestro procedimiento habitual. Así por ejemplo, para el dispositivo mtd5 (userdata), la ejecución de búsqueda de cadenas empieza a ofrecer datos interesantes sobre el usuario del teléfono, como por ejemplo claves wireless precompartidas o la presencia de bases de datos en la carpeta /data

Una de las ventajas del método pull de ADB es que podemos procesar ficheros en lote. A tenor del posible interés que pueda tener, procesamos la carpeta de datos al completo trasladándola al equipo del investigador:

Una vez en nuestro equipo, un listado del directorio basta para comprobar que las probabilidades de encontrar información confidencial del usuario son elevadas:

Correo, contactos, YouTube, Facebook, Google Apps, Gmail, Seesmic, MMS ... hasta algún juego (iMobsters, os lo recomiendo, por cierto). Aunque algunas bases de datos están vacías (por ejemplo la de Facebook, que se crea al lanzar la aplicación pero que nunca he utilizado) algunas sí contienen información relevante. La información que contienen estas bases de datos es la que te puede provocar serios problemas si pierdes un teléfono de estas características, y ahora veremos por qué.

Por ejemplo, de la base de datos de Seesmic podemos, aprovechando que es un formato SQLite, extraer a partir del esquema la información de las cuentas declaradas en la aplicación:

De la base de datos de correo también es fácil obtener las claves:

En otras ocasiones encontraremos bajo los directorios shared_prefs distintos ficheros XML en claro que también incluyen información interesante:

De donde se puede comprobar que la clave de mi servidor FTP en el teléfono es 1234. Prometo cambiarla :)

Conclusiones

Yo no voy a entrar a comentar aspectos de usabilidad de Android, porque para eso hay cientos y cientos de publicaciones que ya lo han hecho antes que yo. Lo que sí quiero hacer es un comentario a la vista de lo que hemos estado analizando.

En mi caso particular, este Android corre en un Nexus One. Es un teléfono que no incorpora cifrado, como sí puede incorporarlo, por ejemplo, una BlackBerry o un Nokia E71. Esto representa un grave problema para los usuarios: si pierdes un teléfono que está pensado para que desarrolles toda tu vida online en él, el volumen de la pérdida normalmente será elevado.

Este problema no es sólo de Android o del Nexus One. Es de muchos más teléfonos que permiten que el usuario tenga todas sus aplicaciones favoritas en él sin forzar el uso de cifrado y contraseñas maestras, lo que provoca que todas las claves sean accesibles ante un evento de pérdida o robo con métodos similares a los mostrados: Redes sociales, correo, mensajes, contactos, etc.

Ante esto, lanzo a los desarrolladores de Android el mensaje de que al menos yo agradecería que el sistema soportase nativamente cifrado, y estoy seguro que los usuarios también lo terminarían agradeciendo. Hago extensivo el mensaje a los demás desarrolladores de sistemas de teléfonos inteligentes, como no podía ser de otro modo, aunque sé que es un mensaje que no suele despertar simpatías, por las implicaciones en la usabilidad (y por ende ventas) que suele tener el cifrado.

Un saludo,

En cualquier investigación forense es vital la obtención de una línea temporal que permita recrear la sucesión de eventos. Cuando los eventos son numerosos, complejos y concurrentes, tener una representación gráfica de dicha sucesión puede ayudar al investigador a plantear y resolver el caso.

Os dejo una reseña sobre log2timeline, una útil aplicación que nos permitirá generar ficheros compatibles con, entre otros, líneas temporales SIMILE. La aplicación permite igualmente generar líneas temporales compatibles con ArcSight Commen Event Format (CEF), XML estándar para procesar con CyberForensics TimeLab (CFTL), CSV, mactime, SQLite y TLN.

Log2timeline puede leer datos de ficheros de eventos de Windows, exif, favoritos e historia en los principales navegadores (Firefox, Opera, IE, Chrome), logs IIS, pcap, pdf y otros tipos de ficheros que están descritos en la documentación. Se pueden enumerar ejecutando log2timeline -f list.

A modo de prueba, aquí tenéis el código que se genera a partir de un histórico de navegación de Google Chrome, una vez exportado para ser procesado con SIMILE. En este caso en concreto se muestra el total de la actividad de mi navegador Chrome en una corta sesión de ejemplo. Nótese la utilidad que puede tener para el investigador la presencia de datos relacionados con el comportamiento del usuario, como por ejemplo

• type: [START_PAGE - The start page of the browser] (URL not typed directly)
• type: [TYPED - User typed the URL in the URL bar] (directly typed)
• type: [LINK - User clicked a link] (URL not typed directly)

Instalación de log2timeline

El proceso es bastante simple, ya que tiene únicamente tres pasos: perl Makefile.PL, make y make install (como root). No obstante, y dependiendo de lo que tengas instalado en tu máquina, es frecuente que al crearse el fichero make se presenten algunos warnings con aquellos módulos que no han sido encontrados. La mayoría son prerrequisitos para poder parsear distintos tipos de fichero, en mi caso faltaban File::Mork, HTML::Scrubber, Image::ExifTool, Net::Pcap y XML::LibXML. Aunque puedan parecer simples avisos, y aunque no vayamos a usar el soporte para los ficheros afectados, es conveniente instalar los módulos para prevenir fallos en el funcionamiento de log2timeline (lo que incluye operativas básicas como listar los tipos de logs procesables, los tipos de salida generables, etc)

Un saludo,

Con el curioso nombre de Xplico se ha publicado una herramienta de análisis forense orientada al tráfico de red.

En funcionamiento de Xplico es tremendamente sencillo: con esta herramienta se pretende que el investigador, una vez obtenido un fichero de tráfico de red, sea capaz de extraer, clasificado por categorías, la totalidad de datos de las aplicaciones intervinientes en la generación de dicho tráfico. Así, por ejemplo, de una captura pcap Xplico extraerá correos, contenidos HTTP, llamadas VoIP, sesiones SFTP/FTP, etc. Xplico soporta un buen número de protocolos y a buen seguro irá aumentando su compatibilidad.

Otras características interesantes de la herramienta son su capacidad de extracción de datos en formatos SQLite/MySQL, capacidad de proceso en tiempo real, soporte IPv6 y una buena modularidad, ya que cada componente es en sí un módulo, lo que facilita el uso de porciones de nuestro interés en detrimento de módulos que consideremos innecesarios.

La documentación está disponible en este enlace, y Xplico se puede descargar sin coste alguno a través de http://www.xplico.org/download. Está liberado según GNU/GPL.

Un saludo,

Raptor es, probablemente, una distro forense más de las miles que hay. En este sentido nada nuevo bajo el sol, si bien es cierto que es un producto bastante simplificado, prácticamente reducido a un imager, lo cual tiene sus ventajas e inconvenientes según lo que pretendamos hacer con él.

Si traigo a Raptor a portada es porque es la única disftribución que conozco que tiene una versión para plataformas Intel, y otra optimizada para Macintosh PowerPC. En ambos casos, se trata de una distrubición live Linux, con capacidad para la extracción de imágenes forenses de sistemas de ficheros FAT32, NTFS, HFS+ y EXT3, y con capacidad de generación de imágenes en formatos .E01, DD, .DMG (formato Macintosh de imagen de disco)

Raptor se puede descargar, sin coste para el usuario, a través de este enlace.

Los chicos de Sans Forensics han publicado una guía con la que manejar el frontal de análisis forense Autopsy será prácticamente coser y cantar.

Autopsy es un frontal Web que permite realizar operaciones de análisis forense sirviendo como interfaz gráfico del popular juego de herramientas forenses The Sleuth Kit (TSK). TSK es un referente en el mundo del análisis forense mediante la línea de mandatos, y que permite a los investigadores lanzar auditorías forenses no intrusivas en los sistemas a investigar. Probablemente la mayor concentración de uso de TSK la tengamos en dos tipos de análisis: análisis genérico de sistemas de archivos y líneas temporales de ficheros.

TSK tiene una larga historia, ya que emplea el mismo código que The Coroner's Toolkit (TCT), de Wietse Venema y Dan Farmer, y puede ser empleado en plataformas Linux, Mac OS X, CYGWIN, OpenBSD, FreeBSD y Solaris. Es posible su instalación en Windows, aunque es poco frecuente, ya que la mayoría de suites forenses suelen estar disponibles como live CDs de Linux, aprovechando no sólo la abundancia de aplicaciones libres, sino la integración de las mismas.

Para facilitar la labor de los investigadores, TSK y Autopsy suelen ir de la mano, lo que hace que no sea necesario invocar constantemente la línea de comandos cuando queremos inspeccionar una imagen. Un paso a paso para aprender los conceptos básicos de este frontal puede resultar bastante útil para principiantes. En este ejemplo se describe cómo abrir un caso y cómo vincular una imagen de un sistema a investigar al mismo. También se muestra cómo acceder a los procedimientos básicos de investigación (líneas temporales de actividad, verificación de la integridad de una imagen, secuenciador de eventos ... etc.)

Podéis ojear el paso a paso en este enlace.

Un saludo, y buen fin de semana.

A través del más que recomendable blog de SANS Forensics, leo que la versión 1.3 del SANS SIFT Workstation está disponible.

SANS SIFT Workstation es un appliance VMware preparado para realizar actividades de análisis forense. Es compatible con los principales formatos, léase Expert Witness Format (E01), Advanced Forensic Format (AFF), y las capturas brutas dd (usadas con frecuencia en los volcados de memoria)

Incluye las siguientes herramientas, algunas de las cuales ya hemos comentado en el blog con anterioridad:

The Sleuth Kit
ssdeep & md5deep
Foremost/Scalpel
WireShark
HexEditor
Vinetto
Pasco
Rifiuti
Volatility Framework
DFLabs PTK
Autopsy

Si alguien tiene interés en conocer algo más sobre alguna de estas herramientas que deje un comentario, y trataremos de hacer una demo para verla en funcionamiento. En cuanto a sistema de ficheros, SANS SIFT Workstation nos permite trabajar con las arquitecturas típicas: Windows (MSDOS, FAT, VFAT, NTFS), Mac OS (HFS), Solaris (UFS) y Linux (EXT2/3).

Podéis descargar SANS SIFT Workstation en http://forensics.sans.org/community/downloads/ (requiere registrarse en el portal SANS, 1,5 GB)

Las iniciativas de este tipo son siempre bienvenidas, pero habida cuenta del excesivo tamaño que ocupa, yo particularmente prefiero llevar en un lápiz USB o DVD un Backtrack o similar.

Un saludo,

He estado haciendo algunas pruebas con un producto de Accessdata que se llama FTK Imager, orientado principalmente a la adquisición y tratamiento de imágenes de dispositivos de almacenamiento, para ser posteriormente usadas como de evidencias forenses.

Este producto tiene una gran ventaja para los que no se llevan bien con la línea de comandos: su interfaz gráfica, que permite crear imágenes de todo tipo con cómodos asistentes y funciones agrupadas en menús. Además, al tratarse de una herramienta Windows, FTK Imager es fácil de instalar y permite operar con dispositivos sujetos a controladores no universales, que muchas veces dificultan su montaje otros sistemas y que dotan al análisis en este tipo de plataformas de una laboriosidad adicional que no todo el mundo puede afrontar.

La interfaz presenta un aspecto amigable, con todas las funciones principales integradas. Para la prueba he dispuesto de una llave USB de Inves de 32MB, vieja como ella sola, pero que sigue dando buenos resultados para transportar ficheros pequeños.

La herramienta permite generar imágenes de dispositivos de almacenamiento en varios formatos. En este caso, he optado por una imagen dd, lo que nos permitirá analizarla en otros entornos y sistemas si así lo deseamos.

Una vez realizada la imagen, podemos añadirla como evidencia al caso, a través de las funcionalidades de FTK:

En esta captura apreciamos como en el espacio libre hay rastros de un fichero en el que se puede ver un patrón ._.s...°h.e.r.n.a.n...d.o..c.e.r.t.i...°f.i.c.a.d.o..._.f.CERTIF~1P12

Cualquier herramienta básica de recuperación nos permitirá obtener más información sobre ese fichero borrado de una manera no segura en la llave USB. Por ejemplo, Restoration:

Recuperamos

Y voilá, hemos recuperado un fichero que corresponde a mi certificado digital emitido por la FNMT. Este certificado PKCS #12 está protegido y no puede utilizarse sin la clave privada de cifrado utilizada en el proceso de exportación original, con lo que en un evento de pérdida y recuperación del mismo por terceros malintencionados, no es factible su reutilización. En caso contrario, cualquiera podría haber suplantado mi identidad.

Moraleja: cifra siempre tus dispositivos móviles, y siempre que te deshagas de ellos, bórralos de una manera segura.

Un saludo,

Me gustaría dejaros un enlace a otra de las excelentes herramientas que Mandiant pone a disposición de los usuarios sin coste alguno. Se trata de Mandiant Highlighter, y la tenía apuntada en mi to-do desde que el pasado 18 de febrero se liberase la versión 1.0.1 del programa.

Se trata de una sencillísima aplicación para resaltar y localizar cadenas de búsqueda en ficheros (logs, especialmente), así como representar gráficamente las cadenas para facilitar la búsqueda y localización de las mismas. En procesos de análisis forense es frecuente, además de efectuar procesado masivo y completo de registros, inspeccinar logs en busca de patrones determinados y concretos. Desde grep hasta el bloc de notas he visto de todo, y a la hora de efectuar estas tareas, como podéis imaginar, cada maestrillo tiene su librillo.

En esta captura (ampliable aquí) tenéis un sencillo ejemplo de localización de la cadena error: PAM: en un log real /var/log/messages de un sistema FreeBSD. Esta cadena se escribe en el momento que existe un error de autenticación (en este caso, vía sshd) y que por ejemplo, podría servirnos para detectar un patrón de ataque de fuerza bruta de un servidor SSH. La representación gráfica que aparece a la derecha del log puede ayudarnos a encontrar la cadena en el resto del fichero, o ver rápidamente si es una cadena frecuente o no. Hoy me acostaré tranquilo a sabiendas de que el único que se equivoca autenticando sesiones SSH en mi servidor soy yo :)

Una herramienta sencilla, pero bastante útil. Si os interesan más productos forenses Mandiant, echad un ojo a este enlace.

Good job, Mandiant.

Tiempo atrás hablamos sobre el file carving sobre FUSE. Por resumir un poco, y copiando lo que comentaba en el artículo que os enlazo, comentar que el file carving es un proceso cuya misión es recuperar ficheros en un escenario forense basando el análisis en contenidos y no en metadatos, con lo que este tipo de técnicas son especialmente útiles cuando se pretender recuperar estructuras corruptas. Los tipos usuales de carving son el basado en bloques, el de cabeceras y pies, el basado en características, los limitados en tamaño de fichero, el carving con validación, el carving semántico, el de recuperación de fragmentos y el basado en estructura de ficheros.

Hoy vamos a realizar una tarea de carving mucho más sencilla. De hecho, es la más simple que se me ocurre, y para ello vamos a necesitar un programa que si no aparece en todas las distribuciones forenses, aparece en la práctica mayoría: foremost

Foremost es un programa de consola que permite recuperar ficheros en función de cabeceras, pies y estructura interna de datos. Como gran ventaja, permite procesar directamente imágenes obtenidas mediante dd, directamente sobre la unidad a analizar, y admite otros formatos de imágenes forenses extendidos, como Encase Forensics o Safeback.

Obtención del fuente

Foremost se puede descargar en http://foremost.sourceforge.net. Si queréis usar wget, aquí os dejo un enlace directo

nas# wget http://ovh.dl.sourceforge.net/sourceforge/foremost/foremost-1.0.tar.gz

Compilación

Es muy sencilla. Nada problemática. Se queja de un par de warnings, pero ni caso.

make && make install

Ejecutando el carving

Para empezar, podemos bajarnos dos imágenes de ejemplo, creadas específicamente para poder lanzar herramientas contra ellas. Cualquiera de las dos vale.

http://dftt.sourceforge.net/test11/index.html
http://dftt.sourceforge.net/test12/index.html

Desempaquetamos la imagen, y lanzamos la aplicación. En este caso, le diremos a foremost que localice todos los tipos de fichero (-t all) que tiene internamente definidos sobre el fichero de imagen ejemplo que hemos descargado (11-carve-fat.dd)

nas# /usr/local/bin/foremost -t all -i 11-carve-fat.dd
Processing: 11-carve-fat.dd
|*|
nas#

De una manera automática, se generará un directorio que se llama output, dentro del cual hay un fichero llamado audit.txt que contiene los resultados:

Foremost version 1.0 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sun Nov 30 22:31:59 2008
Invocation: /usr/local/bin/foremost -t all -i 11-carve-fat.dd
Output directory: /mnt/carving/output
Configuration file: /usr/local/etc/foremost.conf
------------------------------------------------------------------
File: 11-carve-fat.dd
Start: Sun Nov 30 22:31:59 2008
Length: Unknown

Num Name (bs=512) Size File Offset Comment

0: 19717.jpg 29 KB 10095104
1: 19777.jpg 433 KB 10125824
2: 20645.jpg 96 KB 10570240
3: 20841.gif 5 KB 10670592 (88 x 31)
4: 321.wmv 7 MB 164352
5: 21929.wmv 1012 KB 11227648
6: 20853.mov 537 KB 10676740
7: 16021.wav 311 KB 8202752
8: 281.doc 20 KB 143872
9: 16693.xls 24 KB 8546816
10: 23957.ppt 13 KB 12265984
11: 23981.zip 77 KB 12278272
12: 16741.pdf 1 MB 8571392 (PDF is Linearized)
13: 19477.pdf 119 KB 9972224
Finish: Sun Nov 30 22:32:02 2008

14 FILES EXTRACTED

jpg:= 3
gif:= 1
wmv:= 2
mov:= 1
rif:= 1
ole:= 3
zip:= 1
pdf:= 2
------------------------------------------------------------------

Foremost finished at Sun Nov 30 22:32:02 2008

Creación y análisis de una imagen real

A modo de ejemplo, vamos a crear una imagen de un dispositivo iPod. No es el dispositivo más indicado para una prueba, pero al ser de poco tamaño, generaremos una imagen de manera rápida. Una vez insertado en el puerto USB, debería aparecer en dmesg algo parecido a:

umass0: on uhub4
da0 at umass-sim0 bus 0 target 0 lun 0
da0: Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 495MB (1015040 512 byte sectors: 64H 32S/T 495C)

Generamos una imagen llamada dumpusb, que será volcada en la carpeta /mnt:

#nas dd if=/dev/da0 of=/mnt/dumpusb

Observamos el resultado del dump, ya que nos hará saber si es correcto o no. En este caso hay coincidencia entre registros de entrada y salida, y se nos informa de la tasa de extracción y consolidación de la imagen.

1015040+0 records in
1015040+0 records out
519700480 bytes transferred in 761.919000 secs (682094 bytes/sec)

Volvemos a lanzar foremost:

nas# /usr/local/bin/foremost -t all -i dumpusb

Con los siguientes (escasos) resultados:

Foremost version 1.0 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Mon Dec 1 00:09:26 2008
Invocation: /usr/local/bin/foremost -t all -i dumpusb
Output directory: /mnt/carving/output
Configuration file: /usr/local/etc/foremost.conf
------------------------------------------------------------------
File: dumpusb
Start: Mon Dec 1 00:09:26 2008
Length: Unknown

Num Name (bs=512) Size File Offset Comment

0: 681667.jpg 15 KB 349013804
Finish: Mon Dec 1 00:09:43 2008

1 FILES EXTRACTED

jpg:= 1
------------------------------------------------------------------

Foremost finished at Mon Dec 1 00:09:43 2008

foremost vs scalpel

En distribuciones forenses más actuales es frecuente encontrar una solución que se llama scalpel. Se trata de una reescritura completa de foremost, es software libre y puede ser empleado con (prácticamente) la misma finalidad.

Scalpel trabaja con un fichero, llamado scalpel.conf, donde se define el patrón de búsqueda de los tipos de fichero que queremos localizar, similar al que utliza foremost (foremost.conf)

Se puede descargar en http://www.digitalforensicssolutions.com/Scalpel/.

Un saludo,