Ya ha pasado casi un mes de la celebración de ForoCiber en la ciudad de Badajoz, como ya os conté en el artículo: “Solución al Forensic CyberSecurity Challenge. Parte 1”, fui uno de los retadores del CTF (Capture the Flag), de la cátedra ViewNext-UEx sobre “Seguridad y Auditoría en Sistemas de Software” que se llevó a cabo en ForoCiber, mas concretamente me encargué del diseño del reto forense.

Como ya sabéis, GLIDER.es, simplemente es un sitio web dónde cuando me apetece y tengo el suficiente tiempo, escribo unas cuentas lineas sobre temas relacionados con la informática forense, hacking o cualquier otro tipo de aventura. La finalidad de esta web, ni es obtener dinero, ni llegar a situar a GLIDER.es como referente en webs de este tipo. Los que me conocéis, sabéis que esto es simplemente un hobbie que terminará cuando ya no me motive escribir este tipo artículos, eso sí: ¡Espero que todavía quede mucho para que llegue ese día!. Os estaréis preguntando para que os cuento todo esto ahora, el motivo es sencillo, últimamente no dispongo de todo el tiempo que me gustaría para escribir artículos en GLIDER.es, y tengo claro que escribir aquí nunca se convertirá en una obligación, como ya dije, es un simple entretenimiento.

Durante este mes habéis sido muchos los que me escribisteis para preguntar cuando publicaría la segunda parte del artículo: “Solución al Forensic CyberSecurity Challenge”. Os agradezco enormemente vuestro interés por los temas que aquí público, y sobre todo por los ánimos que me dais para continuar, pero tenéis que entender que escribir un artículo técnico con las características de los aquí publicados requiere mucho tiempo, tiempo del que no siempre se dispone. Pero como mas vale tarde que nunca, y lo prometido es deuda, hoy por fin tengo un rato para sentarme tranquilamente delante del ordenador, desconectar de otros quehaceres (que a veces también es necesario), y escribir un artículo mientras disfruto de un sabroso café con leche. Así que os voy a contar la forma de resolver el: Forensic CyberSecurity Challenge.

En primer lugar quiero pedir disculpas a los que habéis leído la Parte 1 de este artículo, en ella os explicaba un método un tanto bizarro (extravagante) para unir las 157.288 partes del fichero de la imagen forense. Ya os comenté que esa no era la forma mas “cómoda” para realizar el concatenado de ficheros, pero en ese momento (la competición estaba abierta) no podía dar una pista que favoreciera a los competidores que visitaran GLIDER.es respecto de los que no, por eso di una pista para que los que estaban atascados pudieran continuar en cierto modo, pero a cambio, tendrían que invertir mucho tiempo en ejecutar todos los comandos que en ese artículo detallé, y no eran precisamente pocos 😉

Hoy os voy a contar la forma “elegante” de resolver este reto forense, no quiero decir con esto que sea la única ni la correcta, simplemente es la que yo he diseñado. Como sabéis, para ganar el reto, y por ende los premios como ordenadores portátiles, drones… Había que obtener la “flag” de cada reto y hacerlo en el menor tiempo posible. El procedimiento utilizado no importaba, solo importaba ser el primer en obtener la bandera.

Para comenzar con este #CiberRETO primero tendréis que conseguir el fichero: “IMAGEN_DIFU_ForoCIBER_m4nu_GLIDER_Forense_MD5_e1b316594ff7bf55c8f8488f5aff4a7b.tar.gz” en el que se basa la competición, ahora que ya se terminó la prueba, el fichero es público y lo podéis descargar desde AQUÍ.

 

Síntesis para la resolución del Forensic CyberSecurity Challenge:

 

1.) Comprobamos que el HASH del fichero descargado, corresponde con el HASH MD5: e1b316594ff7bf55c8f8488f5aff4a7b, esto simplemente es necesario para detectar una posible corrupción en el fichero, no tiene ningún tipo de implicación en la resolución final del reto.

Fig. Comprobación del hash

 

2.) Al descomprimir el fichero: TAR.GZ, observamos que este contiene miles de archivos, la cosa se empieza a poner interesante…

Fig. Descompresión del fichero

 

3.) Mas concretamente vemos que contiene ni mas ni menos que 157.288 ficheros, además, por la nomenclatura de los ficheros, podemos deducir que se trata de una imagen forense troceada, y a muy mala leche por cierto.

Fig. Listado del contenido

 

4.) Par unir esta imagen troceada en 157.288 partes, podemos utilizar el método “cat” que os contaba en el primero de los artículos, pero existen métodos mas ágiles y sobre todo, mas cómodos, para realizar esta tarea, como por ejemplo un: for i in $(ls); do cat $i >> salida, lo que viene a ser un bucle de toda la vida. Básicamente, toma el primer elemento, lo concatena con el segundo, el resultado con el tercero, luego el cuarto… y así hasta 157.287 veces.

Fig. Bucle para concatenar la imagen

 

5.) Como os podéis imaginar, este no es un proceso precisamente rápido, imaginaos que alguien os hace esto mismo, pero con un disco de 1Tb, gracioso, ¿verdad?. Después de unos cuantos minutos, o horas, en función de la potencia de computación de vuestro PC, tendréis una bonita salida con una imagen ya concatenada y lista para tratar. Quizás llegar hasta este punto, ha sido la parte mas “extraña” del reto.

Fig. Imagen forense refundida

 

6.) Como seguro que lo habéis hecho todo bien, ya podéis montar la imagen para ver su contenido, nada que con un buen “mount” no logréis hacer. Al ser una imagen “full”, también se pueden utilizar herramientas forenses como: EnCase, Autopsy, FTK… Para visualizar su contenido. En este caso, ya os anticipo que a diferencia de otros retos forenses, aquí no hay que recuperar información eliminada, todo lo necesario está a la vista. Esto puede parecer que facilita la tarea forense, pero la realidad es bien distinta. ¿Cuantos de vosotros al no haber encontrado nada de primeras, habéis tratado de recuperar información eliminada de la evidencia?, me imagino que bastantes, esos preciosos minutos que habéis invertido en tratar de recuperar una información que no estaba, es tiempo que no le estabais dedicando a buscar “bandera”. La informática forense es así, muchas veces hay que tomar caminos incorrectos para ir eliminado posibilidades y así lograr dar con el camino correcto.

Fig. Montando la imagen forense

 

7.) Este es el contenido de la imagen:

Fig. Contenido de la imagen forense

 

8.) Si abrimos el fichero: “drivers pc Asus manu 2012.zip”, vemos que contiene un fichero tipo .DOC.

Fig. Fichero ofimático

 

9.) Pero al intentar descomprimir el fichero tipo .DOC, nos damos cuenta que este tiene contraseña, así que aquí nos quedaremos estancados a no ser que se nos ocurra otra solución.

Fig. Zip con contraseña

 

10.) Volviendo al resto de ficheros, localizamos una fotografía con el logotipo de la canción “We will rock you” de Queen, lo que debería ser una pista suficiente para unos avezados hackers como vosotros, os debería guiar hasta el famoso diccionario de contraseñas: rockyou.

Fig. Pista para obtener la contraseña

 

11.) Con nuestro querido fcrakzip y el diccionario rockyou no tardamos mas de un minuto en romper por fuerza bruta la contraseña que permite descomprimir el fichero.

Fig. Fuerza bruta a la contraseña

 

12.) Efectivamente, la contraseña es la correcta y podemos descomprimir el fichero en cuestión.

Fig. Explotación del diccionario

 

13.) Aunque observemos que el fichero llamado “drivers pc Asus manu 2012.doc” es del tipo ofimático, al tratar de abrirlo con: OpenOffice, Word o XPS nos da un fallo que nos impide abrir este documento.

Fig. Extracción del documento

 

14.) En este momento la intuición nos debería guiar para decirnos que algo raro está pasando con este fichero .DOC. En efecto, a veces las apariencias engañan, simplemente visualizando el fichero en cuestión con un editor hexadecimal, podemos ver que la cabera hexadecimal del fichero corresponde con 52 61 72 21, en vez de ser D0 CF 11 E0, que sería la correcta para un fichero tipo .DOC. Pero… – ¿A que corresponde la cabecera hexadecimal 52 61 72 21 ?, – Si nos vamos a nuestro listado de principales cabeceras hexadecimales, podemos ver que 52 61 72 21 corresponde con un fichero empaquetado tipo .RAR. Siendo así, solo nos quedará abrir este fichero con un descompresor para .RAR en vez de un visor de .DOC.

Fig. Cabecera hexadecimal

 

15.) Otra forma mas sencilla de descubrir el truco, es a través del comando “file”, de Linux, gracias al cual podemos ver fácilmente cual es el tipo de un fichero.

Fig. Uso del comando file

 

16.) Descomprimimos el fichero. RAR y vemos que en su interior, contiene una carpeta, dentro de esta, nos encontramos una serie de imágenes y ficheros. Nos tocará ir analizando una por una hasta encontrar algo que nos llame la atención.

Fig. Contenido del fichero

 

17.) Al comprobar los metadatos de la imagen llamada “ara.jpg”, encontramos algo interesante, en efecto, hemos descubierto la flag dentro de la etiqueta MAKE, de la imagen. Eso sí, siento deciros que el resto de ficheros son “paja” es decir, solo están ahí para estorbar y confundir a los competidores.

Fig. Metadatos del la imagen

 

Si eres uno de los participantes del Forensic CyberSecurity Challenge que no pudo resolver el #CiberReto, no te desanimes si al leer este artículo te ha parecido que la solución era muy fácil, realmente no era tan sencilla. Ahora con la solución delante se ve todo muy fácil, sin embargo este reto estaba especialmente pensado para obligar a los participantes a tomar varios caminos y que los fueran descartando al comprobar que no eran los correctos. Así que no te desanimes y si te gusta esto, sigue pegándole fuerte a los CTF 😉

Salu2

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.