Hola,
Como ya he comentado anteriormente infinidad de veces, para poder realizar un buen análisis forense es imperativo conocer bien el sistema de ficheros con el que estamos trabajando. Hoy quiero dejar unas notas sobre ext3, habida cuenta que es el sistema de ficheros más frecuente en Linux, y vamos a apoyarnos una vez más en las herramientas The Sleuth Kit de Brian Carrier que nos permitirán obtener una visión introductoria a bajo nivel del sistema de ficheros.
Para ilustrar los conceptos vamos a recurrir a un ejemplo práctico sencillo, en el que tenemos un disco de 1 GB que presenta los siguientes contenidos:
Como buenos analistas forenses nunca trabajamos directamente sobre la evidencia a no ser que no quede más remedio, con lo que obtenemos una imagen del disco que utilizaremos para el análisis. Podéis escoger el método que más os guste, mi recomendación es emplear dd en la línea de mandatos. Una vez obtenida la imagen podemos hacer algunas averiguaciones interesantes. En primera instancia averiguamos qué estructura de particionado presenta el medio:
Es posible obtener confirmación del tipo de partición a través del empleo de un editor hexadecimal, acudiendo al Master Boot Record, ya que la tabla de particiones primarias comienza en el byte 446.
Ese primer offset nos indica si el sistema de ficheros es arrancable o no (00 en nuestro caso, no lo es). Los tres siguientes offsets indican la configuración CHS (Cilinders, Heads and Sectors) y en el offset 450 aparece nuestro número preferido, el 83, que indica que la partición es nativa Linux. Este indicador lo comparten además de ext3, otros sistemas de ficheros como xiafs, ext2, o reiserfs.
Una vez obtenidos estos datos, procedemos a inspeccionar la partición nativa de Linux. De la ejecución de mmls que mostramos antes obtenemos que dicha partición comienza en el offset 2048, con lo que lanzamos fsstat teniendo en cuenta dicho offset de la partición dentro de la estructura del disco:
Esta ejecución nos confirma que la partición nativa de Linux es ext3. La ejecución del comando es mucho más larga, ya que ofrece información para los metadatos, los contenidos y los grupos de bloques, detallando en cada caso los hallazgos más significativos. Observemos estos tres grupos de información con detenimiento:
Tal y como se observa, con relación a la información de metadatos, se nos presenta información sobre algo llamado inodes. En derivados de UNIX, se denomina inode a aquella estructura de datos que contiene información sobre un objeto del sistema de ficheros (típicamente, ficheros y directorios) con la excepción de sus contenidos y su nombre. La descripción de lo que debe contener un inode viene determinada en la especificación POSIX, y abarca numerosos metadatos, como por ejemplo, el UID, GID o los timestamps del objeto.
Para averiguar qué inodes están siendo utilizados por los contenidos de mi disco ejemplo recurrimos a la ejecución de fls, sin olvidar nuestro offset de 2048 bytes que es donde da comienzo la partición que estamos analizando:
En esta ejecución comprobamos que los metadatos de nuestro fichero prueba.txt están ubicados en el inode número 12. Mediante istat, profundizamos en el estudio de dicho inode:
Esta ejecución nos muestra información relevante para el análisis forense, como por ejemplo, más allá de qe el inode está asignado como cabía esperar, los siempre útiles timestamps, el UID y GID del propietario (0,0, es decir, del root), los modos, el tamaño y el número de enlaces a dicho inode, en este caso, sólo uno.
A nadie debería sorprenderle el hecho que na vez identificado el inode de nuestro fichero, podamos desplegar los contenidos provocando que el sistema consulte dicho inode, y para ello empleamos icat:
Tampoco debería sorprenderle a nadie que al examinar el bloque 2048 encontremos exactamente los mismos contenidos. Observad la ejecución de istat, y comprobaréis que al final incluye una información muy relevante para el análisis: los bloques directos empleados por el fichero, es decir, los bloques donde están los datos propiamente dichos, que pueden ser invocados mediante blkcat:
En resumen, a través de un sencillo ejemplo hemos aprendido a identificar el particionado de un disco con detalle, y hemos relacionado tres conceptos fundamentales a la hora de realizar un análisis forense en un sistema de archivos: los metadatos, los contenidos y los bloques donde están ubicados los datos. Estas tres capas se dan siempre dentro de un sistema de ficheros ext3, y el esquema del sistema de ficheros es extrapolable a otros sistemas como por ejemplo, NTFS, donde en vez de inodes hablamos de entradas MFT, y donde en vez de bloques, hablaremos de clusters.
Para comprender un sistema de ficheros en profundidad habría que desarrollar estas notas introductorias, y entrar en otros aspectos relevantes como los bloques de arranque, el journaling, o cómo el sistema de ficheros conserva la trazabilidad de los cambios, y sería interesante comprender cómo se enlazan el concepto de superbloque, las tablas de descripción de grupos de bloques, las tablas de inodes y finalmente, los inodes y bloques de datos que hemos visto. He querido simplificar el artículo lo máximo posible para centrarlo en lo que es más visible desde el punto de vista del análisis, y dejo para otra ocasión hablar de estos otros conceptos.
Un saludo,
Qué chulo Sergio, me va a venir fenomenal para un «expediente X que anda por aquí» -;)
Me ha parecido muy interesante y detallado. Se ha explicado paso a paso todo lo realizado. Felicidades por el artículo. Saludos.
Enhorabuena por el artículo. Espero con ganas el resto de artículos de esta serie ;)
Soy un n00b en estos lares así que puede que haga una pregunta estúpida, pero… como sales los valores de los offsets, son siempre iguales?
Tommy,
En el caso del MBR, sí, son siempre iguales, siempre que el sistema sea compatible con IBM PC.
Tienes más información en http://en.wikipedia.org/wiki/Master_boot_record
Un saludo!