PDF de programación - Solución al Reto Hacking VIII de Informática 64

Solución al Reto Hacking VIII de Informática 64

Julio 2008 © Daniel Kachakil


Introducción

Este documento describe una solución al Reto Hacking VIII de Informática 64,
el tercero de la segunda temporada, que se publicó el 4 de julio de 2008 en la siguiente
dirección web:




http://retohacking8.elladodelmal.com



Pistas

por lo que no se publicaron pistas previas al inicio del mismo.


Supongo que el planteamiento del reto estaba bastante claro desde el principio,



1

Solución al Reto Hacking VIII de Informática 64



© Daniel Kachakil

Fase 1: Análisis forense de un fichero ".pcap"

Como viene siendo habitual en los últimos retos, para acceder a la primera fase
teníamos que registrarnos con un nombre de usuario y una dirección de correo válida,
donde recibiremos la contraseña correspondiente generada aleatoriamente. Una vez
registrados y autentificados, accedemos a la fase 1.

http://www.fileinfo.net/extension/pcap
http://es.wikipedia.org/wiki/Pcap

Por si alguien se enganchó en ese mismo punto, si no conocemos la extensión



En esta ocasión no teníamos que encontrar ningún tipo de vulnerabilidad, ya que
por primera vez el reto no iba de eso, sino que tendremos que demostrar nuestras
habilidades detectivescas en un reto de análisis forense. Todavía no tenemos muy claro
nuestro objetivo, pero sí el primer paso, que era tan sencillo como descargarse un
fichero comprimido que contenía otro llamado Trama.pcap


del fichero nunca está de más hacer una búsqueda previa:




Rápidamente vemos que se trata de un fichero que contiene capturas de paquetes
de una red (obtenidas mediante un sniffer). Un excelente programa para abrir este tipo
de fichero es el Wireshark (anteriormente conocido como Ethereal).



Una vez descargado e instalado, basta con abrir el fichero con este programa
para visualizar toda la secuencia de paquetes que ha sido interceptada y almacenada.
Vemos que hay todo tipo de secuencias de diferentes protocolos clásicos como DNS,
NetBIOS, ARP, ICMP, HTTP, UDP, TCP, etc.


Llama la atención que desde el principio del fichero nos encontremos con tantos
paquetes marcados como MSNMS, es decir, del protocolo de MSN Messenger. Si
aplicamos un filtro para visualizar únicamente este protocolo (tecleando msnms en el
cuadro de texto Filter de la ventana principal), tal vez podamos leer la conversación y
enterarnos de alguna pista.


Fig. 1 – Visualizando el fichero en Wireshark con un filtro aplicado









2

Solución al Reto Hacking VIII de Informática 64



© Daniel Kachakil


Buscando más información sobre este protocolo, nos encontramos con que es
propietario de Microsoft y no está publicado, por lo que todo lo que aparece en los
siguientes enlaces, no es oficial y es fácil que no esté actualizado, que a veces no esté
del todo completo o incluso que tal vez sea incorrecto:

http://www.hypothetic.org/docs/msn/index.php

http://msnpiki.msnfanatic.com/index.php

De momento no hace falta entender todo el protocolo que utiliza este programa,

ya que si inspeccionamos a ojo el contenido de los paquetes podemos observar las
direcciones de correo electrónico correspondientes a cada usuario y leer la conversación
que aparece como texto plano en los paquetes MSG. Era la siguiente:


Mensaje

De

Nº
814 MaloMalisimo buenas
832 MaloMalote hola
838 MaloMalisimo
846 MaloMalote ok
…

2839 MaloMalisimo
2861 MaloMalote ok, suerte!




te dejo que creo que me siguen

te envio los posibles puntos de encuentro y lo que me pediste

fgIAAAMAAAAi1gsAAAAAAAAAAABQAHQAbwBzAEQAZQBFAG4AYwB1AGUAbgB0AHIAbwAuAHAAbgBnAA...




Es evidente que el texto de la conversación no da la solución a la fase, pero ya
nos aporta una pista, puesto que habla de un envío de "algo". Si analizamos más a fondo
el contenido de otros paquetes, observamos que el inmediatamente posterior al 846 (es
decir, el 854, asumiendo que la vista sigue filtrada para visualizar solamente el
protocolo MSNMS) contiene el siguiente texto codificado en Base-64, concretamente
en el parámetro Context:



Decodificando dicho texto comprobamos que la parte final corresponde con el
texto claro PtosDeEncuentro.png, por lo que parece evidente que ese "algo" que se
enviaba era un fichero PNG. Si nos entretenemos decodificando el resto de mensajes en
Base-64 que se envían por el mismo protocolo, encontraremos un encabezado de PNG,
e incluso podremos recomponer el fichero completo, pero eso solo es la miniatura que
se envía incluso antes de aceptar y comenzar la recepción del fichero.


El fichero real se envía directamente del emisor al receptor (P2P), sin utilizar los
servidores de MSN que actúan como intermediarios en las conversaciones normales.
Por tanto, quitamos el filtro en el Wireshark y visualizamos de nuevo toda la trama de
paquetes para darnos cuenta de que existe un tráfico bastante importante por TCP/IP
entre las direcciones 192.168.1.105 y 192.168.1.107. Desde esta última IP se inicia el
SYN en el paquete 985, recibe el ACK en el 986 y queda claro que a partir de ahí existe
una secuencia o stream TCP que parece tener su interés para superar el reto.


Para recomponer la secuencia basta con pulsar con el botón derecho sobre
cualquier paquete de la misma y seleccionar del menú contextual (o del menú Analyze)
la opción Follow TCP Stream. Entonces nos aparecerá una ventana con toda la
secuencia TCP/IP entre ambas direcciones. Sin embargo, tras echarle un vistazo general



3

Solución al Reto Hacking VIII de Informática 64



© Daniel Kachakil

a toda la secuencia, determinamos que solo nos interesa el tráfico de un único sentido,
ya que es el que contiene el fichero propiamente dicho. Por tanto, seleccionamos del
cuadro de lista desplegable la opción que muestra solamente los paquetes enviados
desde 192.168.1.107 hacia 192.168.1.105 y exportaremos el contenido a un fichero.
Para ello es imprescindible seleccionar la opción adecuada (RAW), ya que de otra forma
el fichero resultante no se corresponderá con la secuencia original.






Fig. 2 – Opción "Follow TCP Stream" en Wireshark




Una vez exportado el fichero, comprobamos que la cabecera del PNG aparece
después de 112 bytes, pero incluso eliminando esa parte, el resultado no parece
corresponder con un fichero PNG válido. Revisando la secuencia con un editor
hexadecimal comprobamos que cada cierta distancia aparecen algunos bloques de datos
sospechosos, ya que no parecen corresponder al fichero. Analizando este tipo de
bloques llegamos a la conclusión inicial de que tienen una longitud de 52 bytes, que
comienzan por "78 05 00 00" (hex) y aparecen a intervalos regulares de 1404 bytes, así
que optamos por eliminarlas pero aún así no se visualiza el PNG. Más adelante veremos
que esto no es del todo cierto…

Está claro que nos hemos dejado algo por el camino y es que con todo lo que

hemos hecho, no era tan difícil toparse con un encabezado "PK" y con un Cliente.exe
que aparecía por ahí muy cerca. La clave del fallo es que hemos asumido erróneamente
de que se trataba del envío de un fichero PNG, cuando en realidad se trata de un envío
simultáneo de dos ficheros, tal y como podemos comprobar si además del anterior (854)
analizamos también el contenido del paquete 940 (de nuevo el Context que aparece en
Base-64), ya que contiene el texto Cliente.zip y eso nos llevará a adoptar otra
metodología de trabajo orientada a diferenciar y extraer los bloques de cada fichero por
separado.


Ahora es cuando entran en juego esas cabeceras de 52 bytes que antes habíamos
eliminado tan alegremente, ya que contienen información muy valiosa que no podemos
ignorar (incluso en el caso de haberse transferido un único fichero, este método no
habría funcionado). Si volcamos todos esos bytes y analizamos minuciosamente todas



4

Solución al Reto Hacking VIII de Informática 64



© Daniel Kachakil

las cabeceras que comienzan por "78 05 00 00" y que habíamos asumido que tenían una
longitud total de 1404 bytes, nos damos cuenta de que la mayoría de bytes son cero o
son idénticos en todas ellas, pero otros varían, tal y como podemos apreciar en esta tabla
cuyos valores están todos en decimal:


Offset
general Tamaño
1404
1404
1404
1404
1404
1404
1404
1404
1404
1404
2451
1404
1404

60
1464
2868
4272
5676
7080
8484
9888
11292
12696
14100
16551
17955

1
120
120
120
120
120
120
120
120
120
120
120
120
120

2

5
5
5
5
5
5
5
5
5
5
5
5
5

Bytes (posición relativa)
14
5
185
0
0
187
5
185
5
187
185
10
10
187
15
185
21
185
187
15
26
185
31
185
36
185
185
42

13
0
0
72
72
144
144
216
32
216
104
176
248
64

9
211
212
211
212
211
212
211
211
212
211
211
211
211

21
34
3
34
3
34
3
34
34
3
34
34
34
34

22
214
25
214
25
214
25
214
214
25
214
214
214
214

Fichero
PNG
ZIP
PNG
ZIP
PNG
ZIP
PNG
PNG
ZIP
PNG
PNG
PNG
PNG



Por las cabeceras, sabemos que el primer paquete corresponde al fichero PNG y
el segundo al ZIP, por lo que no resulta complicado concluir que los bytes 5, 9, 21 y 22
tienen una relación directa con el fichero. Puede que indiquen su tamaño total, o que
sean parte de algún identificador, aunque tampoco nos importa demasiado para lograr
nuestro objetivo, que no es otro que separar ambos ficheros. Sin embargo, si juntamos
las partes correspondientes al ZIP, no conseguimos recomponer el fichero, ya que no se
podrá descomprimir correctamente con ningún descompresor.


Por otro lado, en la tabla hemos calculado el tamaño del paquete restando el
offset actual del siguiente, pero