Data Carving Challenger

Al hilo de nuestra anterior entrada sobre zombies, en otra de esas maniobras de parecidos razonables hoy vamos a coger la pala y cavar, cavar y cavar hasta que saquemos los cuerpos del delito, aunque los ingleses tienen un verbo algo más extraño para estas tareas, se llama carving (trinchar), Data Carving.

En el reto forense de hoy nos han proporcionado un raw de aproximadamente 41 MB, esto es un archivo binario cuyo contenido es desconocido, podemos imaginar que ha sido extraído de un disco corrompido o formateado, nuestra labor es extraer el contenido del disco y descubrir de forma inequívoca lo que en el había. Antes de ponernos los guantes de manipular cadáveres, vamos a repasar algunos conceptos necesarios:

La magia de los números

Como es sabido, los ficheros no son más que un conjunto binario que, agrupado por ciertos patrones diferencia a unos de otros. Por ejemplo, si esos números en binario forman la combinación 25 50 44 46 al comienzo de un archivo sabremos que estamos delante de un PDF (además que la traducción a hexadecimal es %PDF). Bien, los sistemas operativos se basan en los conocidos como “magic numbers” para identificar los archivos y saber que acciones puede ejecutar con ellos. En Linux el comando file es el encargado de identificar los magic numbers al principio y final de un archivo para saber qué es, si hacemos un man file:

“file tests each argument in an attempt to classify it. There are three sets of tests, performed in this order: filesystem tests, magic number tests, and language tests. The first test that succeeds causes the file type to be printed. The type printed will usually contain one of the words text (the file contains only printing characters and a few common control characters and is probably safe to read on an ASCII terminal), executable (the file contains the result of compiling a program in a form understandable to some UNIX kernel or another), or data meaning anything else (data is usually `binary’ or non-printable). Exceptions are well-known file formats (core files, tar archives) that are known to contain binary data. When adding local definitions to /etc/magic, preserve these keywords. People depend on knowing that all the readable files in a directory have the word “text” printed. Don’t do as Berkeley did and change “shell commands text” to “shell script”. Note that the file /usr/share/file/magic is built mechanically from a large number of small files in the subdirectory Magdir in the source distribution of this program.”

Comprobamos que “file” hace 3 test, 1º pregunta al filesystem para saber como lo identifica, 2º comprueba los números mágicos, 3º hace comprobaciones de lenguaje. Es sencillo engañar al comando file. Podemos manipular el directorio /usr/share/file/magic y dejar el file con cara de poker ya que en ese archivo está el repositorio que asocia números y formatos de archivo:

O podemos cogernos un editor hexadecimal, hacer unos cambios aquí y allá y encontrarnos con que un script es realmente,,, ¡un ejecutable MS-DOS!:

File System

Ahora que sabemos cómo identificar a los archivos tenemos que saber que no todos los sistemas operativos los guardan de igual forma, dependerá exactamente del formato que tenga el file system, FAT 16/32, NTFS o UFS /JFS son algunos de los formatos que rigen la arquitectura de los file sytem. Desde una perspectiva forense debemos saber que dependiendo de varios factores nuestros archivos se pueden encontrar fragmentados (es decir, divididos en regiones de memoria distintas), además esa fragmentación no tiene por qué ser consecutiva, puede haber trozos que han sido sobrescritos por otros (por ejemplo, tras un borrado y escritura) y se han perdido o incluso el archivo puede estar comprimido (compresión NTFS), esto puede complicar mucho las cosas,,, a priori.

Manos a la obra

Ahora que tenemos conocimientos básicos sobre los archivos y su estructura de almacenamiento es momento de abordar el “DFRWS Forensic Challenge Images”. Para este reto aconsejo bajar una distribución forense, la que he utilizado yo es Helix 2008 RC1, disponible aquí como appliance de máquina virtual. Dentro de esta distribución descargamos y descomprimimos el raw y ejecutamos foremost . Esta herramienta es la llave inglesa del Data Carving, si hacemos un foremost –h vemos todas las opciones:

foremost version 1.5 by Jesse Kornblum, Kris Kendall, and Nick Mikus.

$ foremost [-v|-V|-h|-T|-Q|-q|-a|-w-d] [-t ] [-s ] [-k]

[-b ] [-c ] [-o] [-i]

-V - display copyright information and exit

-t - specify file type. (-t jpeg,pdf ...)

-d - turn on indirect block detection (for UNIX file-systems)

-i - specify input file (default is stdin)

-a - Write all headers, perform no error detection (corrupted files)

-w - Only write the audit file, do not write any detected files to the disk

-o - set output directory (defaults to output)

-c - set configuration file to use (defaults to foremost.conf)

-q - enables quick mode. Search are performed on 512 byte boundaries.

-Q - enables quiet mode. Suppress output messages.

-v - verbose mode. Logs all messages to screen

Con el archive de configuración por defectoy y sin habilitar la opción de detección de indirección de bloques es capaz de recuperarnos 25 archivos:

Foremost started at Wed Oct 28 11:22:24 2009

Invocation: foremost dfrws-2006-challenge.raw -o forensic.txt

Output directory: /home/bagside/Desktop/forensic.txt

Configuration file: /etc/foremost.conf

------------------------------------------------------------------

File: dfrws-2006-challenge.raw

Start: Wed Oct 28 11:22:24 2009

Length: 47 MB (49999872 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00003868.jpg 280 KB 1980416

1: 00008285.jpg 594 KB 4241920

2: 00011619.jpg 199 KB 5948928

3: 00012222.jpg 6 MB 6257664

4: 00027607.jpg 185 KB 14134784

5: 00031475.jpg 206 KB 16115200

6: 00036292.jpg 174 KB 18581504

7: 00040638.jpg 292 KB 20806656

8: 00041611.jpg 1 MB 21304832

9: 00045566.jpg 630 KB 23329792

10: 00094846.jpg 391 KB 48561152

11: 00000009.htm 17 KB 4691

12: 00004456.htm 22 KB 2281535

13: 00027496.htm 349 KB 14078061

14: 00028244.htm 50 KB 14460928

15: 00029529.htm 183 KB 15118957

16: 00032837.doc 282 KB 16812544

17: 00045964.doc 71 KB 23533568

18: 00028439.zip 157 KB 14560768

19: 00030050.zip 697 KB 15385752

20: 00045015.zip 274 KB 23047680

21: 00007982.png 6 KB 4086865 (1408 x 1800)

22: 00033012.png 69 KB 16902215 (1052 x 360)

23: 00035391.png 19 KB 18120696 (879 x 499)

24: 00035431.png 72 KB 18140936 (1140 x 540)

Finish: Wed Oct 28 11:23:19 2009

25 FILES EXTRACTED

jpg:= 11

htm:= 5

ole:= 2

zip:= 3

png:= 4

Sin embargo el resultado no es satisfactorio siempre, por ejemplo en algunas imágenes nos encontramos:

Existen herramientas alternativas como photorec y testdisk capaces de detectar más archivos, el problema es que el número de falsos positivos es altísimo (a mí me ha detectado unos 3000 archivos, 20950 de ellos falsos xd). Si habilitamos las opciones de búsqueda avanzada de foremost, o buscamos algunas extensiones en concreto encuentra exactamente lo mismo, tampoco es capaz de recomponer las imágenes fragementadas, ¿qué podemos hacer en este caso?

Vamos a centrarnos por ejemplo en nuestro amigüito el puercoespín, archivo 5 de los listados anteriormente. Si lo abrimos veremos que sale partido, se reconoce el tamaño de la imagen correctamente pero hay algunos bits que están en otro sector así que no puede formarla completamente. Sabemos que el tamaño del archivo son 206 KB, sin embargo descubrimos (esta imagen la obtiene photorec, mientras que foremost no la detecta) que existe un archivo con una foto de Marte en la posición 31532, es decir, 57 Kb después, ¿Dónde están los demás? La foto de Marte comienza cuando la anterior todavía no ha finalizado, quedando ambas corrompidas. Aquí debemos fijarnos en qué posición comienza cada fotografía y el Offset, esto es 31475-31532 para el puercoespín y 31533-32836 para marte. En primer lugar extraemos esos 57 KB del puercoespín a un archivo con el comando dd:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31475 count=`expr 31532 - 31475 + 1` > hedgehog1.jpg

58+0 records in

58+0 records out

29696 bytes (30 kB) copied, 0.0176145 s, 1.7 MB/s

Luego añadimos el trozo que falta a partir del trozo que sí que conocemos de marte:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31753 count=`expr 32836 - 31753 + 1` > hedgehog1.jpg

1084+0 records in

1084+0 records out

Y podemos ver a Rizo:

Una vez que la foto ha sido reconstruida podemos utilizar photorec para obtener los datos exactos del archivo, a partir de ellos recomponer la foto de marte y el resto de fotos detectadas es trivial. Claro está, ese proceso puede ser largo y arduo, además puede diferir según el tipo de archivo.

En el post de hoy hemos visto técnicas de Data Carving y la forma en que trabajan estas herramientas, también hemos visto como el componente humano sigue siendo fundamental, os animo a que practiquéis por ejemplo, con una carpeta en la que habéis borrado todo (sin borrado seguro, obviamente) o un pendrive formateado y reescrito.

Salu2.