lunes, 20 de mayo de 2013

Reto: Flu-Project: "Guy! Where is the info?"

Hace unas dos semanas y pico, Flu-Project lanzó un reto fonrense. Y yo, a su vez, me lancé a resolverlo. ¿Cómo me salió? La respuesta: FAIL. No lo terminé de resolver. Estuve a punto... Pero eso, y mucho más en un caso como este, no sirve. Un caso que se puede dar en un juzgado. Y eso, no puede ser. Aún así, de los errores se aprende. No siempre se van a publicar las cosas que salen bien. Supongo que si pongo aquí todo (o casi todo) lo que hice, también servirá para las demás personas que puedan necesitar hacer una tarea de este tipo.

He de decir que antes de que publicaran el resultado, les envié un correo con el informe de todo lo que había conseguido. Un informe con unas... 16 páginas y, vientitantas capturas que fui haciendo a medida que intentaba resolver el reto. Reto, en el que para ciertas cosas, y por intentar ser muy pijotero, di muchos bandazos. Y creo que ese fue uno de mis errores.

Lo primero que hice cuando leí el reto, desde mi móvil, fue autoenviarme un correo pensando qué iba a tener que necesitar y buscar.

El resumen de lo que me dije fue:

  • ¿Cómo montar la imagen dd? Entre otras cosas encontré que tenía que:
Después de obtener los datos, me dije que tendría que hacer con éstos:

  •  Primero un listado de los mismos, ordenados por fecha.
  •   Después,  se miraría sus metadatos, en los que podríamos ver si les han cambiado las fechas.
  •   Después, se buscaría una herramienta que pueda mirar el journal por si también se han modificado esos metadatos. Sobretodo este me lo dije porque hacía muy poco tiempo que leí a Pedro Sánchez hablando de NTFS y MFT.
  • Localizar ficheros eliminados. 
Esto es lo que me dije bastante antes de ponerme al lío. 

Lo primero de todo, una vez tuve la prueba en el disco, fue mirar sus propiedades:

OSFMount: Datos de la imagen USB
Datos de la imagen USB


Ahora, me tocaba mirar el contenido. ¿Qué hice? Mirar el correo que os he contado, incluyendo alguna cosa más:
  • En Linux, utilizar el mount de la siguiente manera:
    • mount -o loop /media/DiscoWindows/ruta_imagen/usb.dd /media/carpetaDestino
  • Además de hablar de Backtrack, podría utilizar CAINE. 
Con todas las posibilidades, decidí utilizar OSFMount, para Windows. Una vez instalada, y seleccionando la imagen:

OSFMount: Configurando el montaje de la imagen
Configurando el montaje de la imagen
pudimos ver los datos de la imagen clonada y su sistema de ficheros:

OSFMount: Imagen montada: datos como capacidad o sistema de ficheros
Imagen montada: datos como capacidad o sistema de ficheros mostrados
Una vez está montada en modo read-only, tendría que haber podido acceder a los datos desde el explorador como si de otra unidad se tratase. Pero, no pudo ser. Lo curioso es que la primera vez hay que abrirla en modo lectura-escritura. Una vez ya la has abierto así, después no te dará ningún problema si la pones en sólo lectura. Tuve que buscar la razón, y la encontré en la página oficial. El problema estaba en que el sistema tenía que sobre-escribir las ACLs del sistema de ficheros NTFS. Para resumirlo: los permisos referidos al dueño (owner) que se encuentran en el sistema de particiones. Por desgracia, para arreglarlo, y que se sobre-escriban, hay que poner el modo read-write. Primer FAIL. No se puede permitir que haga ese cambio porque el hash de la imagen mientras se analiza cambiaría con respecto a la original. 

Usb.dd, sin montar en modo RW. Usb-copia.dd, montado en modo RW.
Usb.dd, sin montar en modo RW. Usb-copia.dd, montado en modo RW.
De hecho, esta captura la hice tiempo después de haber estado mirando más cosas (la captura tiene numeración 12, y eso que ahora estaríamos por la 4 o 5). Diría que este es otro FAIL (pongamos que es el segundo). El hash debería de mirarlo antes de montar un fichero de este tipo. 

Con este primer fiasco, intenté utilizar la segunda herramienta, P2 eXplorer, o P2X. Inutil, dado que no funcionaba en un sistema de 64 bits. 

Por lo tanto, decidí pasarme a ver si backtrack tenía herramientas que me permitieran realizar un buen análisis:

Posibles herramientas que backtrack tiene para obtener información
Posibles herramientas que backtrack tiene para obtener información
Aunque hice varias pruebas que no me salieron (ni las documenté), me lancé a sacar el hash (cronológicamente antes de haber hecho la comparación de ambos ficheros arriba), lanzando

#sha256deep /mnt/descargas/usb.dd > usb_hash_sha256deep.txt

con el resultado

a98e5e401c022c9b0a17b35dade09410b4e84a946569f7a2e5d7c1c7455f4104  /mnt/descargas/usb.dd

La siguiente opción fue intentar montar la imagen con

 #mount -o loop,ro /mnt/descargas/usb.dd /mnt/usbPericial/

pero me dio problemas. Se me insistía en que pusiera el sistema de ficheros. Y en ese momento no fui capaz de hacerlo. Y eso que ya tenía la información desde el principio. De las dos opciones que tenía: 
  1. Buscar cómo se le indican el sistema de ficheros de los USB
  2. Buscar otra herramienta que pudiera abrir la imagen en modo sólo lectura
no fui capaz en ese instante de realizar la primera. Tercer FAIL. Tendría que haber buscado más en ese instante, porque me hubiera ahorrado un montón de quebraderos de cabeza. Ya veréis más adelante la razón. 

La otra herramienta que intenté utilizar fue scalpel. Pero tampoco tuve mucho éxito (y no documenté lo que hice con ella). Además, estaba teniendo en cuenta que quería seguir intentando abrir la pericial en modo sólo lectura. 

Estando en el punto en el que me encontraba, decidí buscar otra distribución, para ver si encontraba otras herramientas: CAINE

Al abrir el dispositivo donde tenía guardado el fichero para analizar, se podía ver que el tamaño indicado era diferente al que me mostraba Windows. 109MB para Windows, 115,1MB para CAINE.

CAINE. Tamaño del fichero: 115,1 MB
Tamaño del fichero: 115,1 MB
Herramientas que utilicé en ese instante y que no me me ayudaron:
  • Xmount: 
  • Autopsy: que me permitió añadir la imagen, pero no abrirla. Encontró algunas fechas, y sacó alguna firma MD5. Ese tipo de firmas las descarto, por considerarse tanto obsoletas como comprometidas. Se desaconseja totalmente su uso. No son fiables. Cualquier descripción que quiera dar a entender esa circunstancia será valida. Diría que este es el cuarto FAIL. Más adelante podría utilizar esta herramienta correctamente, tal y como lo explicaré. En ese momento no le dediqué el tiempo suficiente. 
Una herramienta me aportó más datos. Y me fié de ella, aún haciéndome alguna cosa rara. Es el programa de recuperación de datos foremost. Quinto FAIL, muy estrepitoso.

CAINE: foremost -i /mnt/usb/usb.dd -q -v -T
foremost -i /mnt/usb/usb.dd -q -v -T

CAINE: foremost -i /mnt/usb/usb.dd -v -T
foremost -i /mnt/usb/usb.dd -v -T

CAINE: Resultados de las últimas ejecuciones de foremost
Resultados de las últimas ejecuciones de foremost
Siendo muy curioso que dos ejecuciones del mismo comando diesen distintos resultados. ¿Cómo es posible que cada vez detectase distintas cosas? Es más. En algún momento me sacaba unos cuantos cientos de ficheros.

Con los ficheros obtenidos, y sin tener en cuenta que había imágenes (.jpg) repetidas, pude encontrar estas dos fotos:

Imágenes rescatadas
Imágenes rescatadas

Y busqué sus metadatos utilizando gThumb:

CAINE: Foremost: Metadatos de primera imagen, cuyo nombre es el que ha asignado foremost.
Metadatos de primera imagen, cuyo nombre es el que ha asignado foremost.

CAINE: Foremost: Metadatos de segunda imagen
Metadatos de segunda imagen
En ese punto, quise comprobar que tanto las fotografías originales como los thumbnails/previews eran los mismos, siendo afirmativa la respuesta.





Recordemos que ahí donde nos encontramos en la explicación de lo que hice, todavía no había abierto el fichero .doc. Aún me faltaba mirar más cosas en ambas fotografías: ver si tenían información oculta utilizando esteganografía (estenografía, o como se escriba). Diría que este fue el sexto FAIL. Me obcequé mucho en este otro punto dedicándole mucho, mucho tiempo. 

Para ello, utilicé la herramienta xsteg, un front para stegdetect. Si se le pasan las fotos deseadas, te intenta identificar si se han utilizado técnicas estenográficas con ellas. Como suele suceder, en una primera pasada no me ha dio ningún resulado positivo, pero la segunda, y poniendo el valor de sensivity a 10...

CAINE. Tenemos un resultado positivo en xsteg
Tenemos un resultado positivo en xsteg
Ahí, ya era consciente de que tenía que encontrar alguna forma de sacar los datos ocultos en la fotografía indicada.

En esos instantes, y viendo que había cosas que no iban bien del todo, y que CAINE me estaba dando un buen dolor de cabeza (tal y como comenté en el post de la review de esta distribución), acabé volviendo a backtrack. En esta ocasión, instalé algunas librerías/herramientas: xmount, gisomount, lupin-casper y ahí pude volver a intentar hacer un montaje como tiene que ser:

#mount -t ntfs -o loop,ro /mnt/usb/usb.dd /mnt/usbPericial

funcionando en esta ocasión. ¿Por qué no me funcionó antes? No lo se. Podría ser porque me faltaba alguna librería. O porque no acababa de poner del todo bien los parámetros. Lo que si se es que de haber conseguido hacerlo funcionar desde el principio, algún quebradero de cabeza sí me hubiera ahorrado. 

Además de obtener los nombres originales de los ficheros existentes (no borrados), se podía ver que había un fichero de texto que foremost no me mostró. Además, pude realizar otro análisis estonográfico:

Montaje: mount -t ntfs -o loop,ro /mnt/usb/usb.dd /mnt/usbPericial y stegdetect
Montaje: mount -t ntfs -o loop,ro /mnt/usb/usb.dd /mnt/usbPericial y stegdetect
Además, se pudo ver el árbol completo de los ficheros no eliminados de todo el dispositivo clonado:

Listando todo el dispositivo: ls -lRa
ls -lRa
Se podía apreciar que los ficheros almacenados eran del 4 de abril de 2012, siempre teniendo en cuenta lo que muestra el sistema, y sin haber analizado una posible manipulación de las fechas. 

Además, tal y como se puede ver en la captura de arriba, la carpeta lost está vacía, y en la siguiente captura, se podría ver que el fichero venecia.txt tampoco contiene información:

cat venecia.txt
cat venecia.txt
Queriendo volver a mirar la foto que almacena información oculta, intenté utilizar XStegSecret, sin ningún resultado. Porque, en algún punto, había intentado utilizar alguna de las tantas herramientas que empezaban con por steg:  steghide, stegbreak... En los que pedían una contraseña. Incluso utilizando diccionarios no fui  capaz de "entrar". Además, en algún punto, encontré una entrada en un blog (que he perdido), indicando el autor que stegdetect lo veía un poco "buggy". Aún así, me seguí obcecando. Séptimo FAIL.

Por lo que decidí pasarme a ver si el fichero word me podía ayudar a descubrir alguna forma de poder sacar la contraseña de la esteganografía. Por lo tanto, y dado que en el LiveCD de backtrck no tenía ninguna herramienta ofimática, copié los ficheros obtenidos en una carpeta accsible desde Windows y me pasé a ese sistema para intentar abrirlo. Algo que no se debería de hacer para mantener los ficheros read-only. Como al intentar abrirlo se me pedía una contraseña, no me quedaba otra que volver a backtrack para ver si había alguna forma de obtenerla por otro lado. ¿Qué hice? Por misterios de la vida, conseguí configurar bien autopsy. Y me permitió sacar unas cuantas cosas. 

Primero: el fichero word tenía 11 palabras:

Autopsy: Algunos datos encontrados por autopsy en el fichero word
Algunos datos encontrados por autopsy en el fichero word
Además de encontrar ficheros eliminados y sus contenidos:

Autopsy: Fichero eliminado y que se ha encontrado, cuya conversión sería: "123abc."
Fichero eliminado y que se ha encontrado, cuya conversión sería: "123abc."
y

Autopsy: Fichero eliminado y que se ha encontrado
Fichero eliminado y que se ha encontrado
Analizando los clusters, y mirando alguno que otro más o menos al alzar, me encontré con:

Autopsy: Un dato que dice "123abc.."
Un dato que dice "123abc.." 

que, según otra vista del mismo cluster, se puede deducir que pertenecen al fichero venecia.txt:

Autopsy: Datos que se puede deducir pertenecen a venecia.txt
Datos que se puede deducir pertenecen a venecia.txt
Octavo FAIL: En este caso, si bien fui capaz de averiguar que la cadena "3132 3361 6263 2e0a" pertenecía a 123abc. no fui capaz de identificar que las cadenas terminadas en "==" eran base64. Algo que tenía que haber sabido. Me sonaba mucho, pero, aún así, no lo vi. Si lo hubiera hecho, la solución la habría encontrado y finalizado con éxito.

Además, también se podían ver datos de la estructura de ficheros (cuya captura no voy a poner). 

Ya, otra vez en Windows, se pudo abrir el fichero de office:

Contenido del enVsb3MK.doc
Contenido del enVsb3MK.doc
Utilizando la herramienta FOCA, sacar sus metadatos:

Abriendo el fichero con "La FOCA"
Abriendo el fichero con "La FOCA"
A partir de estos datos, podemos ver que el usuario que lo ha creado es "bit". Además, se puede ver que se ha modificado dos veces. Aún así, no es posible ver qué cambios se hicieron ni qué datos había en esas otras versiones.

En ese instante, me faltaban dos cosas. Una, buscar otra vez el significado de las cadenas encontradas en los ficheros eliminados. Otra, volcarme otra vez a las fotografías. Me decanté por lo segundo. Además de querer encontrar algo en la foto que se nos indicaba que se había usado jphide para ocultar información, el tamaño de la segunda me hacía pensar que a lo mejor también podía contener alguna cosa guardada. 

De todas las herramientas que encontré, una llamada StirMark Benchmark me ayudó a sacar alguna cosa un tanto curiosa. La lancé para ambas imágenes. y a su vez, para cada una de ellas, generó un montón de ficheros bmp derivados de las originales. Uno de ellos me pareció muy, muy curioso porque, en una de ellas, al añadirle ruido (incluso en el informe que escribí lo comparé con la nieve que salía en la televisión):

Nieve en la imagen 2009*.jpg: patrón de rejilla/cuadrícula
Nieve en la imagen 2009*.jpg: patrón de rejilla/cuadrícula
Se puede apreciar que la nieve no genera un patrón del todo aleatorio. Si uno se fija bien, se puede apreciar que tenemos una especie de rejilla. Algo que no sucedía en la otra imagen.

Utilizando una herramienta que se llama ImageHide v2.0,  fui capaz de abrir ambas fotos, y en la que empieza por 2009*.jpg, consiguió sacar información inteligible: 

Mirando para sacar información de las imágenes extraidas del .dd
Mirando para sacar información de las imágenes extraidas del .dd
Y aquí lo dejé. Y eso que intenté utilizar más programas de estegoanálisis.

Total, como habréis visto, me obcequé en mirar algunas cosas todo el rato. Y di muchos bandazos. Tendré que buscar otros retos de este tipo y hacerlos por mi cuenta, sin mirar el resultado, para mejorar mucho la búsqueda de datos ocultos y de pruebas periciales. Además, busqué en sitios que no he indicado, como por ejemplo, utilizando algún editor hexadecimal para ver si era capaz de romper el sistema de contraseñas del .doc (¡iluso de mi!).

¿Qué me hubiera faltado que me hubiera gustado haber visto? Además de las cosas que se me quedaron en el tintero, me hubiera gustado mucho haber tenido tiempo de mirar las tablas MFTs tal y como explicó Pedro Sánchez. 

Ahora, la pregunta para los que hayaís llegado hasta aquí: Viendo lo que os he contado: ¿Qué habríais hecho en mi lugar? Es decir: ¿Qué herramienta o paso hubierais cambiado?

No hay comentarios:

Publicar un comentario