Solucionario Reto Hacking VIII (I de II)por Dani Kachakil

***************************************************************************************
Solucionario Reto Hacking VIII (I de II)
Solucionario Reto Hacking VIII (II de II)
***************************************************************************************

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

Supongo que el planteamiento del reto estaba bastante claro desde el principio, por lo que no se publicaron pistas previas al inicio del mismo.

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.

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

Por si alguien se enganchó en ese mismo punto, si no conocemos la extensión del fichero nunca está de más hacer una búsqueda previa:

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

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
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:


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:

fgIAAAMAAAAi1gsAAAAAAAAAAABQAHQAbwBzAEQAZQBFAG4AYwB1AGUAbgB0AHIAbwAuAHAAbgBnAA...

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 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 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:


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 comprobamos que existe un salto inesperado que resalta otro error del planteamiento ya que aparentemente tenemos un paquete de tamaño 2451, cuando en realidad en ese bloque se esconden dos paquetes. No se trata de localizar la secuencia en hexadecimal "78 05 00 00", sino de leerla e interpretarla correctamente. Esos 4 bytes nos están indicando la longitud del resto del mensaje, en orden inverso (en nuestro caso, 0578 en hexadecimal, o lo que es lo mismo, 1400 bytes).

Por ello debemos corregir la información anterior e interpretar correctamente los paquetes correspondientes a ese bloque, ya que todo parece indicar que nos falta el último trozo del fichero ZIP.


Ahora que ya hemos conseguido separar ambos ficheros, descomprimimos el ZIP, extrayendo y ejecutando el fichero Cliente.exe (que requiere .NET Framework 2.0), comprobando que se trata de una sencilla aplicación que nos solicita una contraseña para obtener una supuesta clave de cifrado.

Para analizar su funcionamiento interno nada mejor que descompilarla usando alguna herramienta como .NET Reflector y localizar el código que se ejecuta al pulsar el botón btRecuperar del formulario principal (llamado Clave). Vemos que hay una instrucción IF que comprueba si la contraseña introducida tiene una longitud de 9 caracteres y además hay un bucle que verifica que dicha contraseña se corresponde con una almacenada en un vector de enteros incluido en el mismo método. Si la contraseña coincide, entonces se realiza una llamada a un servicio web.

Fig. 3 – Código descompilado usando .NET Reflector
El código es tan evidente que no vale la pena elegir un camino que no sea el de determinar la correspondencia directa de los caracteres de la contraseña en ASCII (es decir, chur*****) e introducirla en el programa en ejecución para que continúe ejecutando el resto del código, obteniendo así la palabra clave de cifrado necesaria para superar la fase 1, es decir, [[^^*********^^]]. Por cierto, el fichero PNG no tenía ninguna utilidad para superar el reto, pero por simple curiosidad, este era su contenido:

Fig. 4 – Fichero PtosDeEncuentro.png (reducido)
***************************************************************************************
Solucionario Reto Hacking VIII (I de II)
Solucionario Reto Hacking VIII (II de II)
***************************************************************************************