Las limitaciones del carving forense

Hola,

Lo primero disculparme, esto en vez de un blog para últimamente una tribuna dominical :) Espero disculpéis la escasa actualización.

Durante esta semana comenté con un amigo, a raíz de un trabajo, algunos aspectos del carving forense. Sobre carving hemos hablado en el blog con anterioridad en infinidad de ocasiones, por ejemplo, con foremost, o hablando sobre carving en FUSE. Hoy no quiero hablar de las herramientas en sí, las cuales son abundantes y conocidas, sino de las principales limitaciones que estas técnicas tienen a la hora de aplicarlas.

Casi todas las herramientas de carving funcionan de un modo similar: contienen una base de datos en la que, para diversos tipos de fichero, se especifica una cabecera y un pie característico (si es que está disponible). El carver barre el disco y en cuanto localiza porciones de datos entre la cabecera y el pie, extrae el tipo de fichero. Esta manera de funcionar genera en sí la primera limitación. ¿Qué hacer con aquellos ficheros que no tienen una firma de cierre definida? ¿Tienen todos los ficheros un final constante? Ni mucho menos. De hecho, es raro que así sea. La mayoría de los carvers, por tanto, localizarán la cabecera y se configurarán con un tamaño determinado de modo que una vez localizada la cabecera, se extraiga la porción equivalente al tamaño especificado. Tomemos por ejemplo el fichero de configuración de foremost, el estándar de facto en cuanto a carving.

Si queremos extraer los ficheros PNG utilizados en páginas web, dispondremos de una cabecera (\x50\x4e\x47?) y un pie definidos (\xff\xfc\xfd\xfe), y teniendo en cuenta este tipo de ficheros y su tamaño usual, se le puede asignar un tamaño, que por defecto es de 200000 bytes, para poder realizar la extracción en caso de que no se localice el pie. Sin embargo, si vamos a extraer ficheros BMP, dejamos de tener un pie característico, con lo que el carver trabajará con la cabecera (BM??\x00\x00\x00) y el tamaño en bytes especificado, que por defecto es de 100000 bytes.

Este modo de trabajo conlleva ciertos riesgos, siendo el más importante intentar extraer ficheros sin un pie definido siendo el tamaño de configuración inferior al del archivo que se desea recuperar. Si estamos procesando una imagen, generalmente no habrá problema: si hemos especificado 100000 bytes y la imagen tiene 200000 bytes, en la mayoría de los casos obtendremos una imagen a medias, pero habrá un indicio claro de que en esos sectores del disco merece la pena hacer un estudio más personalizado. El problema lo tienen los ficheros que se corrompen en caso de que el tamaño y contenido no sea el exacto, por ejemplo, los formatos de compresión. Si el tamaño no es el preciso, el fichero se corrompe y el carving fracasa.

Añadido al problema anterior tenemos el segundo gran problema. Los discos son, salvo raras excepciones, un revoltijo de espacio asignado y no asignado, en el que no tiene por que haber correlación. Por ejemplo, si tenemos un sistema de ficheros NTFS:

shernando@hpsergio-linux:~$ sudo fsstat /dev/sda1
FILE SYSTEM INFORMATION
——————————————–
File System Type: NTFS
Volume Serial Number: 0A8C1FAF8C1F9473
OEM Name: NTFS
Version: Windows XP

METADATA INFORMATION
——————————————–
First Cluster of MFT: 786432
First Cluster of MFT Mirror: 11165171
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 – 83424
Root Directory: 5

CONTENT INFORMATION
——————————————–
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 – 12785155
Total Sector Range: 0 – 102281247

Es decir, tenemos 8 sectores de 512 bytes totalizando clústers de 4096 bytes (para discos mayores de 2 GB). Pero tal y como funciona NTFS, el algoritmo de utilización puede provocar problemas en el carving, ya que se utiliza el principio de mejor encaje, es decir, la información no tiene necesariamente que colocarse en sectores consecutivos, sino que se colocará allá donde se genere más eficiencia. Para ficheros pequeños lo normal es que se coloque la información en sectores consecutivos, pero esto no es siempre así para tamaños grandes: la información se colocará siempre en la porción de espacio no asignado más pequeña que pueda acoger los datos, no teniendo por qué haber una sucesión ordenada en el disco.

Añadamos a lo anterior lo que se conoce como slack space, o fragmentación del sistema de ficheros, principio mediante el cual los datos ocupan porciones completas de la unidad mínima definida, incluso si el tamaño no es múltiplo del tamaño mínimo o unitario de dicho sistema de ficheros. Nuevamente para NTFS, si el fichero tiene 1024 bytes, se reserva el tamaño completo del clúster, es decir, 4096 bytes, lo que nos deja 3072 bytes (3 K) de slack space, que pueden contener perfectamente datos de otro fichero que estuviera ocupando ese clúster con anterioridad a la última asignación, con lo que un barrido sector a sector puede perfectamente resultar en mezcolanza de datos de un fichero asignado, y datos de ficheros anteriores en el slack space, lo que complica el método de buscar una cabecera y extraer porciones definidas de datos después. Además de ser un problema para el rendimiento (esta es la razón por la que existen desfragmentadores de disco), las implicaciones forenses son obvias: no siempre podemos esperar que el carving encuentre, para cada tipo de fichero, especialmente si los tamaños son grandes, una ordenación sistemática y correlativa en el disco.

Estas limitaciones que hemos expuesto tienen que hacernos entender que el carving no es, ni de lejos, una aproximación exacta a la recuperación forense. He visto muchas veces cómo la gente confía en que la ejecución de un carver entregará de vuelta todos los ficheros eliminados y cuya información reside en el espacio no asignado. Nada mas lejos de la realidad.

Para mí el carving es una técnica bruta que puede arrojar resultados interesantes, y por tanto, lo ejecuto, pero consciente de las limitaciones, ya que no confío ciegamente en poder recuperar toda la información por el mero hecho de lanzar una herramienta que busca patrones en el sistema de ficheros sabiendo que los sistemas de ficheros son siempre anárquicos en cuanto a la ubicación de los contenidos. Para ello hay que recurrir a la calculadora, a la intervención manual, y a realizar un seguimiento exhaustivo de cómo el sistema ha asignado el espacio para un contenido determinado, y dónde ha colocado exactamente los ficheros. Y esta tarea no se puede realizar con herramientas plenamente automatizadas.

Un saludo,