Hola,
El objetivo de este artículo es comentar cómo podemos trabajar con imágenes forenses fragmentadas. Lo cual hace necesario que antes de ponernos manos a la obra, expliquemos un poco en qué consisten, y cuáles son los escenarios habituales donde podemos encontrarlas.
Imágenes forenses fragmentadas
Cuando se trabaja en la adquisición de medios de almacenamiento, existen dos maneras de operar: adquiriendo el medio completo, bien mediante una imagen o bien clonando el medio, o bien realizar una adquisición fragmentada. Veamos un ejemplo:
En la imagen anterior tenemos un medio de aproximadamente 4 GB y el resultado de fragmentar ese fichero en trozos de 650 MB, para simular una adquisición fragmentada. Esta simulación está hecha a propósito, ya que en el trabajo de campo es relativamente frecuente trabajar con imágenes fragmentadas, siendo los tamaños prototipo 650 MB, 2 GB y 4 GB, dependiendo de la tecnología de adquisición.
Aunque hoy en día la capacidad de almacenamiento y su coste hacen que fragmentar medios no sea algo estrictamente necesario, existen escenarios donde no cabe mas remedio que hacerlo. A bote pronto:
- La tecnología de adquisición opera con formatos fragmentados de imágenes brutas. Por ejemplo, el Talon de Logicube sólo soporta imágenes brutas de 650 MB, 2 GB y 4 GB.
- La adquisición se hace en vivo y sobre la red, por ejemplo, con una sesión netcat. En este caso puede interesar fragmentar para tener mejor control de la transmisión de la imagen.
- Los procedimientos de investigación que apliquen a la organización pueden forzar a escoger tamaños determinados a la hora de realizar adquisiciones. Este factor lo menciona Hal Pomeranz en el artículo Dealing with Split Raw Images in Digital Forensics, aunque yo personalmente nunca me he topado con esta situación.
Sea como fuere, salvo que sea estrictamente necesario, teniendo en cuenta el avance en las tecnologías de almacenamiento y procesado de información, creo que no existe razón para fragmentar los medios a la hora de realizar adquisiciones forenses. En este artículo veremos cómo se trabaja con medios fragmentados, caso de que tengamos que emplearlos en nuestra investigación. Examinaremos dos maneras de proceder: la primera mediante la utilización de librerías para el tratamiento de fragmentado, y la segunda, el empleo de herramientas que soporten el procesado de estos medios. Vamos allá.
Método 1. Uso de librerías para el manejo de medios fragmentados
Una de las enormes ventajas que tiene realizar investigación digital en Linux es la flexibilidad. La cantidad de herramientas disponibles, la constante actualización de las mismas a consecuencia del desarrollo comunitario y la disponibilidad del código, lo que puede ser útil para acreditar fiabilidad y conocimiento en un proceso judicial, hacen que Linux sea la plataforma estrella para el análisis forense a bajo nivel. Una de las muchas herramientas que todo analista forense debe tener instalada en su máquina son las herramientas y librerías AFFLIB.
Dentro de estas herramientas podemos encontrar affuse, una implementación FUSE que permite que los ficheros AFF aparezcan en los sistemas como imágenes brutas, lo que permite el análisis con herramientas que no son capaces de procesar el formato AFF. Una de las opciones más interesantes es el montaje, especialmente de los medios fragmentados. La utilización de affuse es extremadamente sencilla:
shernando@hpsergio-linux:~/split$ sudo affuse image.001 /mnt/sergio
El resultado del montaje es una imagen consolidada formada por las imágenes fragmentadas:
shernando@hpsergio-linux:~/split$ sudo ls /mnt/sergio -la
total 4
drwxr-xr-x 2 root root 0 1970-01-01 01:00 .
drwxr-xr-x 4 root root 4096 2010-11-21 11:13 ..
-r–r–r– 1 root root 3995074560 1970-01-01 01:00 image.001.raw
Esta imagen consolidada puede ser empleada por nuestras herramientas forenses habituales. Comparemos el particionado del medio original obtenido de la imagen original y de la imagen consolidada que acabamos de crear:
Resulta fácil comprobar que el particionado exhibido concuerda con el de la imagen no fragmentada.
Método 2. Uso de herramientas que soportan imágenes fragmentadas
En el ejemplo anterior hemos mostrado el particionado del medio que habíamos escogido enfrentando la salida de la aplicación mmls del sleuth kit tanto a la imagen original como a la imagen consolidada que hemos montado, a partir de los fragmentos, mediante affuse. Este ejemplo nos viene de perlas para ilustrar cómo emplear herramientas que soporten el fragmentado, ya que las herramientas sleuth kit lo soportan, generalmente incorporando el operador – i split, e indicando el patrón de la imagen. Veamos un ejemplo:
¿Sencillo, verdad? :)
Resumen
El uso de imágenes fragmentadas en el análisis forense de medios de almacenamiento es una posibilidad plausible, y que puede venir dada por elementos que no controlamos, como por ejemplo, los procedimientos de extracción, la tecnología que usemos o la necesidad de realizar adquisiciones no convencionales con el sistema en ejecución.
Siempre que se pueda, mi consejo es que no tiene sentido operar con imágenes fragmentadas, ya que sólo añadiremos complejidad al montaje. Si por alguna razón no nos queda más remedio, espero que estos ejemplos os ayuden a comprender mejor cómo podemos afrontar el análisis.
Ups, se me olvidaba …
Confieso que en cierta parte del artículo os he mentido. No lo he hecho con mala intención, creedme. Lo he hecho intencionadamente.
Si alguien detecta dónde está la incongruencia y la quiere comentar … es bienvenido. Si necesitáis pistas, decidlo :)
Un saludo,
Hola Sergio,
Tu mentira intencional creo que está en la afirmación:
«Resulta fácil comprobar que el particionado exhibido concuerda con el de la imagen no fragmentada.»
Según observo el montaje con affuse muestra un archivo image.001.raw que es 1539584 bytes más pequeño que la suma de las 6 partes mostradas al principio image.001 a 006, o que image.raw.
Y acorde con esta diferencia la comparación del particionado que haces con mmls de /mnt/sergio/image.001.raw e image.img no coinciden. El ítem 5 de la partición no coincide, el Unallocated space es más pequeño.
Esta diferencia, creo que se debe a cuestiones con el uso descripto de affuse, podría ser objetable en un análisis forense. Faltaría introducir la autenticación de la evidencia forense con un hash de la imagen sin particionar para poder demostrar que los fragmentos montados como una sola parte o concatenados, coinciden con la evidencia original.
Pero la raíz del problema, que no alcanzo a comprender, es averiguar porque quedó más chico el archivo usando affuse. Allí hay algo para explicar.
Saludos,
Raúl
Raul,
Plas plas plas. Bravo. Muy buen detalle la falta de los hashes de verificación, de todas maneras todo queda reducido a la falta de integridad en el espacio sin asignar del disco (el cual servirá principalmente para realizar carving)
El desajuste esta causado por haber realizado el particionado de la imagen original con el comando split, y posteriormente, por renombrar cada trozo al formato image.0xx (ya que si no están nombrados así, affuse no opera correctamente). Al emplear split por defecto, sin indicar el tipo de extensión que deseamos, los trozos se crearán con las extensiones xaa, xab, xac .. lo cual provoca problemas con affuse. Cuando renombramos provocamos cambios en el sistema de ficheros, que sin llegar a afectar el espacio asignado, sí provocan cambios en el espacio sin asignar.
Este tipo de cosas, que a priori son triviales, son las que a la hora de irte a un juzgado, si topas con un letrado hábil, provocará que la evidencia quede anulada. Así de simple, y así de serio.
Deducir todo era complicado a la vista de las pistas, pero has acertado de pleno. Un saludo, Buen trabajo :)
Gracias Sergio por las explicaciones. Estuvo bueno este desafío. Quedó expuesto un buen ejemplo de los cuidados necesarios en estos casos.
Saludos,
Raúl
Felicidades Sergio por tu blog, que sigo con asiduidad, y en especial por este artículo que me viene bien para iniciarme en el tratamiento de volúmenes grandes. Aunque no me dedico a esto de manera profesional, de vez en cuando alguno de mis clientes me viene con un disco duro para recuperar datos. Normalmente suelo realizar imágenes de una pieza con dd y ddrescue. Hasta la fecha se trataba de discos algo antiguos, de menos de 100 GB.
Sin embargo los soportes más recientes tienen ya una capacidad colosal. Los tres últimos eran Barracudas de 750 GB, 500 GB y 1,5 TB. Por desgracia estaban dañados y no se podía sacar nada de ellos. Todas las utilidades de Linux daban errores I/O. De todos modos resulta lógico pensar que en el futuro habrá que trabajar frecuentemente con estos monstruos, y que la única posibilidad de lidiar con ellos son las imágenes fragmentadas.
¿Qué tal se desenvolvería el software al que se refiere tu artículo con una imagen fragmentada en cientos o miles de archivos? ¿Es posible trabajar con un Barracuda de 1 TB de modo similar a como lo hacíamos con sus antecesores de 40 GB? Este es un tema serio. Los libros que he leído son de hace algunos años y no dan mucha orientación sobre esto. Para empezar, sin un espacio de almacenamiento adecuado la extracción de datos y el análisis habría de hacerse sobre el mismo soporte. Y esto resulta inadmisible en términos profesionales.
Un saludo y feliz fin de semana.
Hola Patxi,
Bienvenido :)
Yo sinceramente, te aconsejo que siempre que puedas evites trabajar con volúmenes grandes. Solo conseguiremos añadir complejidad al montaje, y con el coste de almacenamiento que tenemos hoy en día, yo al menos no veo problema en tratar con discos grandes en cuanto al factor económico se refiere. Como comentas, trabajar con el medio directamente no tiene sentido si podemos generar imágenes que puedan ser tratadas con comodidad en medios externos, o en otros discos, respetando los principios de la cadena de custodia.
Cuando no queda más remedio, las imágenes fragmentadas son tan útiles como las completas, como bien dices. Yo no he tenido problemas cuando he trabajado con multitud de fragmentos en volúmenes muy grandes, salvo lógicamente los problemas que derivan del tamaño en sí, no del número de fragmentos. Un carving a un disco de 2 TB lleva su tiempo, da igual que sea una pieza o 500.
El truco con volúmenes grandes es hacer las cosas con sensatez. Extraer y trabajar sólo con el espacio no asignado cuando se quiere recuperar en el espacio no utilizado, extraer el mapa de inodes/clusteres o las particiones que queremos trabajar, y no todo el disco, etc. Antes de procesar 2 TB a bloque, pensemos cómo acortar el tiempo de proceso.
La mejor prueba la puedes hacer tú mismo, saca unos dd de un disco grande y monta con affuse, y realiza un carving a ver que tal lo ves. Entiendo que no tendrás problema en tener un disco externo sobre el que volcar las imágenes, con lo que te aconsejo eSATA o Firewire para poder hacerlo con rapidez y no morir en el intento :)
Un saludo, y espero sigas disfrutando del blog.
me encantarya ser medico forense eejejejejejjejej los kiero