lunes, 24 de agosto de 2009

Ensayo acerca del tiempo

Parece que rompí la promesa y ahora mismo estoy de vacaciones sentado delante de mi teclado. El motivo, pensar un poco en el tiempo, más concretamente, en la importancia de las líneas de tiempo, (a.k.a. timeline).

Una timeline sería un diagrama cronológico donde cada uno de los registros se correspondería con un evento determinado. Para el caso del análisis forense de sistemas existen una serie de valores asociados a todos los ficheros/directorios y que resultan de especial interés. Se trata de las marcas de tiempo, MAC times, o lo que es lo mismo:

  • Fecha de creación
  • Fecha de modificación
  • Fecha de último acceso
Estos valores podemos consultarlos desde la línea de comandos de Windows, método preferente dado que así no los alteraremos de forma involuntaria:
dir /tc fichero | findstr /r "[0-9]*/[0-9]*/[0-9]*"

dir /tw fichero | findstr /r "[0-9]*/[0-9]*/[0-9]*"
dir /ta fichero | findstr /r "[0-9]*/[0-9]*/[0-9]*"

Los comandos anteriores se utilizan para obtener, respectivamente, la fecha de creación, modificación y último acceso para un fichero determinado. La coletilla se encargará de filtrar la salida para mostrarnos únicamente esta información.

Las diferentes operaciones realizadas sobre ficheros en particiones NTFS provocan la actualización de las diferentes marcas de tiempo. Podemos consultar un resumen de estos procesos en el artículo 299648 de la base de datos de conocimientos de Microsoft.

Muy a tener en cuenta es la forma en que Windows trata el proceso de modificación del parámetro fecha de último acceso. Bajo sistemas de ficheros NTFS este valor no resulta actualizado a veces hasta incluso una hora después de producirse el acceso, todo para conseguir un mayor rendimiento. Según menciona Brian Carrier en su recomendadísimo "Filesystem Forensic Analysis" el valor se almacenaría en memoria hasta su posterior volcado a disco.

El siguiente artículo de la MSDN indica como crear un valor del registro que deshabilitará por completo el proceso de actualización de este valor. De hecho, bajo Windows Vista, esta funcionalidad viene aplicada por defecto.

Si a esto le sumamos que podemos alterar cualquiera de los valores MAC de forma voluntaria ya tenemos una forma burda de dificultar una investigación.

Modificando las marcas de tiempo

Podemos utilizar la API de Win32, concretamente las funciones CreateFile para abrir un fichero y SetFileTime para modificar cualquiera de las marcas de tiempo asociadas al mismo. Sirva como ejemplo el siguiente "programa" generado por un servidor utilizando estos dos artículos de la MSDN:

Changing a File Time to the Current Time
Opening a File for Reading or Writing

El "código" anterior establecerá la fecha de creación de un fichero, indicado como argumento desde la línea de comandos, a la fecha y hora en que se ejecute. Su modificación para otros menesteres resulta realmente trivial. Huelga decir que no me responsabilizo en forma alguna por los efectos negativos que puedan derivarse de su uso (u mal uso).

Y recurriendo a utilidades de terceros dado que en Windows no existe un comando touch integrado como el de los sistemas *NIX, podemos utilizar, por mencionar alguno, el binario ChangeTime. A continuación un ejemplo de uso para modificar la fecha de creación de un fichero, prueba.txt, dejando el resto de parámetros como estaban y consultando sus valores antes y después del proceso:
C:\>ChangeFileTime.exe prueba.txt

 
*********************************************************************
 
Filename : prueba.txt
Creation Time : 20-08-2009 23:55:47
Last Access Time : 20-08-2009 23:55:47
Last Modified Time : 20-08-2009 23:55:47
 
*********************************************************************
 
C:\>ChangeFileTime.exe -c prueba.txt
 
*********************************************************************
 
Filename : prueba.txt
Creation Time : 20-08-2009 23:55:47
Last Access Time : 20-08-2009 23:55:47
Last Modified Time : 20-08-2009 23:55:47
 
*********************************************************************
 
 
Note : You can press if you want to retain previous date/time
 
Creation Time : 20-08-2009 23:55:47
New Date( dd-mm-yyyy) : 20-08-2009
 
New Time( hh-mm-ss) : 23:00:00
 
Last Access Time : 20-08-2009 23:55:47
New Date( dd-mm-yyyy) :
 
New Time( hh-mm-ss) :
 
Last Modified Time : 20-08-2009 23:55:47
New Date( dd-mm-yyyy) :
 
New Time( hh-mm-ss) :
 
C:\>ChangeFileTime.exe prueba.txt
 
*********************************************************************
 
Filename : prueba.txt
Creation Time : 20-08-2009 23:00:00
Last Access Time : 20-08-2009 23:55:47
Last Modified Time : 20-08-2009 23:55:47
 
*********************************************************************

Bueno, aún no está todo perdido, existen otros valores de tiempo que el SSOO no nos muestra pero que, como las meigas, haberlos hailos. Empezaremos hablando de la "fecha de modificación para la entrada de la MFT", pero para eso, bajaremos varias capas de abstracción analizando la estructrura del disco en crudo.

Introducción al sistema de ficheros NTFS

Primero decir que esto es sólo una introducción, por lo que se quedarán muuuchas cosas en el tintero. Para ahondar más en el tema recomiendo nuevamente el libro de Brian Carrier, "Filesystem Forensic Analysis", y el todavía inacabado (esperemos que por poco tiempo) taller de análisis forense de NTFS publicado en Wadalbertia por el compañero Vic_Thor.

NTFS es, sin duda, uno de los sistemas de ficheros más extendidos en la actualidad y apareció en escena con la presentación de Windows NT. Se diseñó con la intención de que fuera fácilmente escalable y su principal característica es que toda la información relacionada con la estructura del sistema de ficheros se almacena precisamente en ficheros, los cuales no son directamente visibles desde el sistema operativo.

El corazón del sistema de ficheros lo compone la MFT, una tabla de registros por cada uno de los ficheros/directorios almacenados en disco. Cada una de las entradas tiene habitualmente un tamaño de 1024 bytes y la primera de ellas apunta a la ubicación del fichero $MFT, o sea, apunta a sí misma. Dado que la ubicación del $MFT no siempre necesariamente coincide, como también sucede con el resto de ficheros de metadatos, para localizarla se utiliza la dirección de inicio almacenada en el sector de arranque ($Boot), el cual siempre se ubica en el primer sector del sistema de ficheros.

Es más dificil leerlo que verlo, así que nos pondremos a ello. Siempre que sea posible trataré de utilizar herramientas 'free' y por ello descargaremos FTK Imager de AccessData, el hermano pequeño de Forensic Toolkit, también de la misma casa.

Para las pruebas voy a utilizar un pendrive de 2GB, el cual está formateado como NTFS y contiene un único fichero, prueba.txt, con el contenido "Hola Mundo". Desde FTK Imager puede analizarse directamente la estructura de un disco físico, pero en su lugar utilizaré las capacidades de la herramienta para crear imágenes de disco en diferentes formatos.

Una vez lanzada, menú 'Archivo', 'Crear imagen de disco...' y seleccionamos 'Unidad física' como tipo para la evidencia de origen. En la siguiente pantalla indicaremos el disco de origen:

FTK Imager: Selección de unidad

Ahora, tras pulsar el botón 'Agregar', indicaremos el tipo para la imagen de disco resultante (dd en nuestro caso) así como la información relativa al elemento de evidencia (Núm. caso, Núm. evidencia, etc). Por último indicaremos la ubicación del fichero resultante, nombre del fichero de imagen sin extensión y un 'Tamaño de fragmento de imagen' igual a 0 (no fragmentar).

Si hemos aceptado el resto de parámetros por defecto cuando finalice el proceso de creación de la imagen se realizará una verificación de integridad, mostrando un resumen del resultado del proceso que incluye las sumas de comprobación manejadas (SHA1 y MD5). Toda esta información y alguna más se almacenará en disco, junto al fichero de imagen, en un txt.

Ahora que ya tenemos la imagen vamos a analizar su contenido. De nuevo en FTK Imager accedemos al menú 'Archivo', 'Agregar elemento de evidencia...' y seleccionamos 'Archivo de imagen' como tipo para la evidencia de origen, localizando a continuación el fichero obtenido en el paso anterior.

FTK Imager: Lista de archivos

En el panel superior derecho, 'Lista de archivos', veremos los ficheros de metadatos, precedidos por el caracter $, asi como el fichero de texto que utilizaremos para las pruebas. Si seleccionamos el fichero $MFT en el panel inferior derecho podremos ver su contenido en hexadecimal. Nótese como la primera entrada, al igual que el resto, comienza con un valor de firma igual a FILE. Otro posible valor de firma es BAAD e indicará que la entrada de la MFT no es válida.

Si nos desplazamos 1024 bytes hacia delante (0400 en hexadecimal), encontraremos el valor de firma que marca el inicio de una nueva entrada, y una delgada línea discontínua incluida por FTK para facilitar su análisis.

FTK Imager: Vista hexadecimal

Ahora ya sabemos identificar los diferentes registros almacenados en la MFT, pero para localizar la entrada correspondiente a nuestro fichero prueba.txt de forma sencilla vamos a utilizar un "truco". Utilizaremos para ello la herramienta Mount Image Pro, la cual podremos descargar en versión trial, válida durante 14 días, desde el sitio oficial.

Una vez instalada y a través de su interfaz pulsaremos el icono 'Mount' seleccionando a continuación el fichero dd que estamos analizando. Aceptaremos los parámetros ofrecidos por defecto y, como resultado, tendremos una nueva unidad de disco que nos permitirá acceder al contenido de la imagen:

Mount Image Pro

Ahora descargaremos las OEM support tools desde la página de Microsoft y extraeremos el binario nfi.exe, el cual nos mostrará información sobre un volumen formateado como NTFS. Bastará con ejecutar:
C:\>nfi.exe F:

En este caso le estoy indicando como parámetro la unidad 'F:', asignada automáticamente por Mount Image Pro para el montaje de la imagen dd. Si analizamos los resultados obtenidos identificaremos las diferentes entradas almacenadas en la MFT, numeradas empezando por 0 y correspondiéndose la última de ellas con el fichero objeto de análisis, prueba.txt:
File 35

\prueba.txt
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

El primer dato que encontramos es el número de entrada de la MFT, seguido del nombre de fichero al que referencia. A continuación están los atributos que conforman la entrada, así como si están íntegramente contenidos en ella (resident) o no (nonresident).

Cada entrada de la MFT está compuesta por una cabecera de un tamaño fijo (48 bytes para Windows 2000 e inferiores o 56 bytes para Windows XP y superiores) y una serie de atributos, almacenados de forma secuencial. A su vez cada atributo está formado por una cabecera de 16 bytes y una serie de datos con estructura variable.

Vamos a verlo "en directo". Desmontaremos la imagen desde Mount Image Pro y volveremos a FTK Imager. Seleccionaremos el fichero $MFT y centraremos nuestra atención en el panel inferior derecho. Si nos encontramos al comienzo del fichero (MFT entry 0) y queremos analizar la entrada número 35, sabiendo que cada entrada de la MFT tiene un tamaño de 1024 bytes:
35 * 1024 = 35840

Y eso que yo y las matemáticas no somos muy buenos amigos.

Para desplazarnos a la dirección deseada botón derecho sobre el panel hexadecimal, 'Ir a desplazamiento...' e indicamos 35840 como el número de bytes en decimal, pulsando el botón 'Finalizar' a continuación.

Vale, ya estamos en la entrada de la MFT asociada a nuestro fichero y hemos descartado los 56 bytes de la cabecera hasta encontrarnos con el primer atributo almacenado. Los primeros 4 bytes de los 16 que componen la cabecera del atributo se corresponden con el identificador de tipo:
10 00 00 00 = 00 00 00 10 = 16

Si tenemos en cuenta que los datos se almacenan en formato litle endian obtendríamos que, en este caso, el valor final se corresponde con el de la $STANDARD_INFORMATION.

Este atributo es siempre residente, existe uno por cada fichero/directorio almacenado y contiene los metadatos asociados al elemento en cuestión. De la cabecera del atributo, cuya estructura es común para todos, también nos interesa el tamaño del mismo, que se almacena en los bytes 5 al 8 y que nos dará el desplazamiento en bytes hasta el comienzo del siguiente atributo:
60 00 00 00 = 00 00 00 60 = 96 bytes

Esto quiere decir que si contamos 96 bytes desde el inicio de la cabecera del atributo nos econtraremos con el comienzo del siguiente atributo:

FTK Imager: Vista hexadecimal

Volvamos a la $STANDARD_INFORMATION y analicemos las 4 marcas de tiempo ubicadas consecutivamente a partir del byte 25. Cada una de estas marcas de tiempo tiene un tamaño de 8 bytes (64 bits) y en NTFS se almacenan en formato UTC. Para nuestro ejemplo serían:
  • Fecha de creación
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de modificación
    53 23 b8 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de modificación de la entrada MFT
    53 23 b8 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de último acceso
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200
Juntos forman los MACE times del fichero prueba.txt (M=Modified, A=Accessed, C=Created y E=Entry modified). Para la interpretación de los valores de tiempo podemos utilizar DCode o el panel inferior izquierdo de la interfaz de FTK, en concreto la pestaña 'Intérprete de valores hexadecimales':

FTK Imager: Intérprete de valores hexadecimales

El valor de modificación de la entrada MFT se actualizará siempre que se modifique cualquiera de los atributos que ésta contiene. Ya hemos encontrado una cuarta marca de tiempo, pero ahora llegan las malas noticias, este valor también puede ser modificado para seguir dificultando una investigación.

Metasploit Anti-Forensics Project

Allá por el 2005, y de la mano de la gente del proyecto antiforense de Metasploit apareció la herramienta timestomp cuya ultima versión disponible de forma independiente tiene ya unos 5 añitos. Desde la publicacion del Metasploit Framework v3.0 el binario timestomp aparece integrado como una extensión del payload meterpreter.

Surgida como una aplicación anti-forense permite modificar los valores para las 4 marcas de tiempo almacenadas en el atributo $STANDARD_INFORMATION de un fichero. Posee también un flag que permite eliminar por completo estas marcas de tiempo para confundir la interpretación de los datos realizada por Encase, pero desde Windows Vista y utilizando la ultima versión independiente disponible no he conseguido aplicar esta funcionalidad.

Vamos a probarla y para ello utilizaremos nuevamente el pendrive original con cuya imagen de disco estábamos trabajando. Obtendremos primero los valores MACE asignados actualmente al fichero:
C:\>timestomp.exe F:\prueba.txt -v

Modified: Saturday 8/22/2009 23:9:26
Accessed: Saturday 8/22/2009 23:9:26
Created: Saturday 8/22/2009 23:9:26
Entry Modified: Saturday 8/22/2009 23:9:26

Y ahora modificaremos todos los atributos MACE, comprobando nuevamente sus valores al terminar:
C:\>timestomp F:\prueba.txt -z "Saturday 8/22/2009 01:00:00 PM"

 
C:\>timestomp.exe F:\prueba.txt -v
Modified: Saturday 8/22/2009 13:0:0
Accessed: Saturday 8/22/2009 13:0:0
Created: Saturday 8/22/2009 13:0:0
Entry Modified: Saturday 8/22/2009 13:0:0

Afortunadamente todavía existe un conjunto de valores MACE asociados a un fichero y que nos servirán para cotejar los resultados obtenidos, permitiendo detectar el uso de herramientas similares a timestomp.

El atributo $FILENAME

Antes de continuar repetiremos el proceso de generación de un fichero de imagen de la unidad física analizada, en este caso mi pendrive. No voy a indicar nuevamente los pasos a dar, basta con volver algunos párrafos atras para encontrarlos.

Una vez abierta nuevamente la imagen mediante FTK nos desplazaremos a la entrada número 35 de la MFT (offset 35840), descartaremos la cabecera y, teniendo en cuenta que el desplazamiento desde el primer atributo, $STANDARD_INFORMATION, hasta el siguiente son 96 bytes avanzaremos hasta el comienzo del mismo.

FTK Imager: Vista hexadecimal

Consultaremos antes los valores MACE de la $STANDARD_INFORMATION una vez modificados mediante timestomp:
  • Fecha de creación
    00 78 57 b1 17 23 ca 01 = sáb, 22 agosto 2009 13:00:00 UTC+0200

  • Fecha de modificación
    00 78 57 b1 17 23 ca 01 = sáb, 22 agosto 2009 13:00:00 UTC+0200

  • Fecha de modificación de la entrada MFT
    00 78 57 b1 17 23 ca 01 = sáb, 22 agosto 2009 13:00:00 UTC+0200

  • Fecha de último acceso
    00 78 57 b1 17 23 ca 01 = sáb, 22 agosto 2009 13:00:00 UTC+0200
Seguimos donde estábamos, los primeros 4 bytes de los 16 que componen la cabecera del atributo se corresponden con el identificador de tipo para $FILENAME:
30 00 00 00 = 00 00 00 30 = 48

Este atributo, al igual que el anterior, es siempre residente y existe uno por cada fichero/directorio almacenado. Dentro de una entrada MFT este atributo se utiliza para contener el nombre del elemento así como una referencia a su directorio padre.

Si contamos 32 bytes desde el comienzo del atributo encontraremos los 4 valores de 8 bytes conteniendo otro conjunto de marcas de tiempo:
  • Fecha de creación
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de modificación
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de modificación de la entrada MFT
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200

  • Fecha de último acceso
    ab c1 b7 d4 6c 23 ca 01 = sáb, 22 agosto 2009 23:09:26 UTC+0200
Si tenemos en cuenta que estos valores únicamente se modifican cuando se crea o mueve un fichero, por lógica deberían ser anteriores a los valores del atributo $STANDARD_INFORMATION; por lo tanto, en nuestro caso, encontramos una evidencia de que las marcas de tiempo pueden haber sido alteradas deliberadamente.

La interpretación de los valores de tiempo dependerá de las características del caso; como decía Einstein "el tiempo es relativo".

Enlaces relacionados

Timeline Analysis Bibliography

The Linux-NTFS Wiki

Wikipedia: NTFS (en, es)

Taller Forensic II. NTFS (Iniciado.....)

Analysis of hidden data in the NTFS file system

Windows Vista Forensic Artifacts

Time and Timestamps

Beating the Daylight Savings Time bug and getting correct file modification times

Anti-Forensics

Metasploit Anti-Forensics Project

Forensic Wiki: Timestomp

Detecting timestamp changing utilities

NTFS Time Stamps --file created in 1601, modified in 1801 and accessed in 2008!!

Conclusión, al menos sabemos más que ayer, pero esperemos que un poco menos que mañana.

No hay comentarios: