Introducción al análisis forense de bajo nivel de sistemas de ficheros ext3

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:

ext3 forensics

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:

ext3 forensics

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.

ext3 forensics

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:

ext3 forensics

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:

ext3 forensics

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:

ext3 forensics

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:

ext3 forensics

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:

ext3 forensics

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:

ext3 forensics

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,

Las implicaciones del cifrado de medios de almacenamiento en el análisis forense

Hola,

Lo primero disculparme por la falta de cadencia en la publicación, pero la verdad, entre la carga de trabajo y que el tiempo libre lo acaba uno dedicando a mil cosas que no implican el uso de un teclado, lo cierto es que hace bastante que no dedico al blog -a vosotros- el tiempo y atención necesarias. Espero me disculpéis.

Hoy quiero hablar un poco sobre cifrado y análisis forense. No será un artículo técnico, es sólo un poco de opinión y alguna que otra idea operativa que quiero compartir con vosotros.

El cifrado de medios de almacenamiento, especialmente en medios portátiles, se está popularizando de una manera gradual, y las razones son obvias: se trata de impedir el acceso ilegítimo a los datos en un evento de pérdida, robo o descuido. Queda mucho por hacer, y son muchas las corporaciones que ni contemplan soluciones de cifrado para ninguno de sus medios, ya sean discos duros en portátiles, almacenamiento en tabletas o discos removibles. En cuanto al segmento del usuario doméstico, la situación no es más halagüeña, aunque los sistemas más modernos le ponen en bandeja a los usuarios la utilización total o parcial de medios cifrados ya sea de una manera nativa, mediante Bitlocker en Windows, FileVault en Mac OS, volúmenes cifrados en Linux, o mediante el empleo de soluciones comerciales y libres no nativas que están disponibles en el mercado.

Desde el punto de vista de la seguridad y la privacidad, los beneficios son obvios, y el sacrificio de recursos es cada vez menor. Atrás quedaron los problemas en el descenso del rendimiento de las máquinas, especialmente en el I/O del almacenamiento, con lo que es saludable recomendar el cifrado hoy más que nunca. Sin embargo, desde el proceso de la investigación forense, la popularización de medios cifrados está provocando un cambio en el paradigma del análisis que requiere una mínima reflexión.

Conviene distinguir dos tipos de escenario, aquel en el que el medio está cifrado de una manera independiente sin relación con un esquema de gestión, y aquel en el que el medio pertenece a un sistema de gestión de cifrado. El motivo para hacer esta distinción no es otro que, en el caso de modelos de cifrado centralizados, existen opciones que no existen en el cifrado independiente, y que pueden suponer una ventaja en el proceso de análisis como veremos a continuación.

Medios de almacenamiento cifrados de manera independiente

En el cifrado independiente poco se puede hacer. La única manera de poder acceder a los datos y realizar el análisis forense no es otra que proceder al descifrado, y esto, salvo la presencia de un cifrado débil que pueda ser comprometido, sólo es posible si se conocen las claves. No hay más alternativa y así de simple es la aproximación: sin claves no hay nada que hacer. Siempre es factible la fuerza bruta, porque algunos usuarios recurrirán a claves débiles, y siempre es posible operar en el medio si el cifrado afecta sólo a una porción del mismo o a ficheros independientes.

En caso que el cifrado sea del medio completo, sin claves no hay nada que hacer, aunque conviene dedicar un poco de tiempo a ver si el usuario, en un descuido, ha dejado las claves de recuperación de emergencia en alguna ubicación que no esté cifrada. Caso de que sólo sean ficheros independientes o porciones las que están cifradas, como por ejemplo carpetas, siempre se puede realizar un examen tradicional de espacio asignado y no asignado y sacrificar los datos que puedan estar presentes en dichas porciones con la esperanza de encontrar evidencias suficientes sin cifrar.

Medios de almacenamiento integrados en soluciones de gestión de cifrado

En soluciones corporativas de cifrado jugamos con una pequeña ventaja, y es que es normal poner a disposición del usuario mecanismos de recuperación de emergencia así como métodos centralizados de asignación de claves. El caso más usual es el método de challenge-response, mediante el cual se puede facilitar al usuario el acceso al medio en caso de que haya perdido su clave. Las soluciones corporativas ofrecen más mecanismos interesantes, como la transferencia de claves, la vinculación de la clave de cifrado a la clave del directorio de identidad que se emplee para autenticar al usuario en la red o la posibilidad de crear políticas de descifrado específicas para ciertos usuarios y máquinas. Todas estas funcionalidades pueden y deben ser aprovechadas para intentar culminar el análisis.

En un evento de investigación prototipo, en el que el usuario no coopera revelando la clave, existen diversas aproximaciones posibles, cada cual con sus ventajas e inconvenientes. Antes de proceder, dado que el descifrado puede provocar pérdida irreparable, es conveniente realizar un clonado del medio para poder trabajar con una copia. Prestad atención a este proceso, ya que las soluciones de cifrado agregan al sistema de ficheros cambios dramáticos en la composición, y en caso de que omitamos el código de arranque, la copia servirá de bastante poco. Clonado bit a bit.

Una vez obtenida la copia de trabajo, y salvaguardado el original, estos son los mecanismos posibles

  • Arrancar el disco cifrado en una máquina virtual o en un equipo físico, e invocar el proceso de challenge-response para poder acceder al sistema operativo. Una vez dentro, realizamos el análisis en ejecución y si se desea, se invoca la desinstalación del software de cifrado, que en la gran mayoría de los casos, provocará el descifrado del medio. Una vez descifrado, el medio será un medio convencional que puede ser procesado de una manera tradicional
  • Otra posibilidad es conectar el disco en modo esclavo a una estación que contenga el software de cifrado, transferir las claves del medio al investigador y usarlas para acceder al medio. Una vez accedido, se puede lanzar una imagen lógica (la del disco completo volvería a ser una imagen cifrada) o se pueden extraer mediante copia selectiva los elementos que interesen
  • Por último, es posible conectar el disco en modo esclavo a una estación que contenga el software de cifrado, transferir las claves del medio al investigador y forzar el descifrado en frío, sin ejecución del sistema

Ninguno de los métodos es perfecto, y resulta obvio el porqué. Arrancar el sistema implica provocar cambios en el sistema a analizar que, en determinadas circunstancias, podrían invalidar la cadena de custodia si las modificaciones no son trazables. Conectar el disco nos impide ver el sistema en ejecución, con las ventajas que esto acarrea, ya no sólo por la observación de las evidencias volátiles, sino por la posibilidad de poder descifrar en ejecución, aunque también es cierto que la amplia mayoría de soluciones centralizadas permite el descifrado en frío.

Donde existe menos claridad y donde no siempre está claro el impacto sobre el análisis es en el proceso de descifrado del medio, ya que salvo raras excepciones, el cifrado afecta a cada sector del disco, y una vez se haya finalizado el proceso de reversión, no existen garantías de que el espacio slack y espacio sin asignar permanezcan inalterados, lo que impide realizar, por ejemplo, un carving para localizar elementos huérfanos o eliminados en el sistema. De entrada hay que suponer que la sobreescritura de cada sector provocada por el cifrado-descifrado provoca la pérdida de la información en las porciones sin asignar, lo que debe hacernos plantear otros mecanismos para recuperar elementos eliminados del sistema.

A modo de propuesta, estos son los pasos que deben considerarse:

  1. Obtención de clones para trabajar y custodia de originales
  2. Conexión esclava y extracción de ficheros y carpetas mediante copia profunda (incluyendo los ficheros del sistema)
  3. Inicialización del sistema operativo para realizar una inspección con el mismo en ejecución
  4. Descifrado del medio
  5. Obtención de una imagen del medio descifrado
  6. Obtención de una línea temporal del medio descifrado
  7. Aplicación de técnicas convencionales en el medio descifrado

Espero que estas ideas os ayuden un poco en vuestros procesos de investigación :)

Un saludo,