Reto Hacking X: Solucionario (III de III)

*****************************************************************************************
- Reto Hacking X: Solucionario (I de III)
- Reto Hacking X: Solucionario (II de III)
- Reto Hacking X: Solucionario (III de III)
*****************************************************************************************

De nuevo nos encontramos ante uno de esos pasos que normalmente necesitan de muchas pruebas, alguna idea feliz y algo de suerte, porque con los datos que tenemos no está claro cuál es nuestro siguiente objetivo. Si lo pensamos bien, hemos obtenido algún nuevo dato al que aún no le hemos dado uso (el nombre del autor y una parte de una ruta local que seguramente sería la típica “Documents and settings”), así que a pesar de no estar seguros de que éste sea el camino correcto, nos centraremos en averiguar la ruta correspondiente a dicho usuario (pero podría haber sido un ataque por diccionario o fuerza bruta al servidor FTP o cualquier otra ocurrencia, quién sabe).

Tras varias pruebas sin éxito basadas en multitud de combinaciones factibles entre el nombre y el apellido (incluyendo solamente las iniciales, con y sin el punto que los separa, etc), junto con palabras que empiecen por “docu” y alguna prueba más, finalmente obtenemos una ruta que nos devuelve un error diferente al 404 (como curiosidad, esta prueba se le ocurrió a Dani recordando el servicio de páginas personales de la universidad y de tantas otras aunque en realidad éstas suelen estar basadas en Unix y no en Windows –que era el caso del reto–):

http://retohackingx.elladodelmal.com/~way.smithers

Parece que vamos por buen camino, puesto que tirando del hilo hemos dado con la ruta del usuario, pero en esta ocasión el servidor no nos lista el contenido del directorio, así que también tocará averiguar el fichero concreto que buscamos. Por los datos que obtuvimos anteriormente, resulta bastante obvio que el nombre del fichero más probable es “peticion_homer_simpson.doc” y así resultó ser. Lógicamente, se trata de un simple fichero de Word (en su formato binario clásico) y podemos abrirlo para ver que su contenido era el siguiente:

Estimado trabajador Homer J. Simpson,

El consejo de administración de la central nuclear de Springfield se pone en contacto con Ud. para solicitar su asistencia en una labor rutinaria carente de todo peligro.

Creemos que Ud. es la persona adecuada para realizar la compra de un material de oficina que le facilitara su labor. Para ello, desde su domicilio, use su terminal para navegar por la siguiente URL:

X

Acuda a la sección Sacapuntas atómicos y compre el modelo AtomicSharpener Krusty Edition. No olvide usar su tarjeta de crédito para realizar la compra.
Al finalizar esta tarea acuda a la cafetería de su centro de trabajo donde tendrá DONUTS GRATIS durante toda la jornada.

Seguramente más de uno estará pensando que esa X la hemos reemplazado nosotros para no exponer la solución final, pero no es así. En el documento no aparecía ninguna URL, por más que intentáramos localizar objetos ocultos desde el propio Word, intentando seleccionarlos, activando el control de revisiones, etc. Nuevamente volvemos a intentar extraer algún metadato con la FOCA y en esta ocasión únicamente obtenemos el nombre de dos usuarios (“Administrator” y “Ultimateuser”), lo que nos podría haber sido de utilidad en algún paso posterior, pero ya os adelantamos que no.

Sin embargo, otro dato que también aparece (incluso en la ficha de propiedades, sin usar la FOCA) es el número de revisiones del documento y en este caso observamos que nuestro documento ha sido modificado y guardado en 5 ocasiones, lo que nos hace sospechar que en alguna de ellas se eliminó algún contenido que seguramente nos pudiera interesar.

En las versiones relativamente antiguas de Word existía una opción de guardado rápido, la cual aceleraba el guardado de las modificaciones de un documento, a costa de aumentar su tamaño y almacenar los cambios de forma incremental. Esta opción se deshabilitó por completo en el SP3 de Office 2003 (tal y como se indica en este artículo de la KB de Microsoft), precisamente para evitar situaciones como esta, en la que veremos cómo podremos recuperar una información que había sido eliminada por el usuario que editó y guardó el documento.

Si abrimos y analizamos el documento con un editor hexadecimal, observaremos que hay una cabecera de un fichero PNG que comienza a partir del byte 5.346 y que termina (IEND) en el byte 37.255. Puesto que en el documento no veíamos ninguna imagen por ningún sitio, parece que el siguiente paso más lógico es el de extraer dicho fragmento y ver qué se esconde en esa imagen. Al hacerlo, vemos una imagen completamente negra de 443 x 50 píxeles, lo que de momento parece bastante inútil.

Seguimos analizando el contenido del fichero y nos encontramos con otra cabecera de otro formato de imagen muy conocido (GIF89a), pero resulta que esa cabecera no aparece en otra parte del documento, sino dentro del PNG que acabamos de extraer hace un momento. Si truncamos la parte inicial de ese fichero hasta llegar a la nueva cabecera y le asignamos la extensión GIF, la imagen es perfectamente visible. Es más, la solución de Román es más simple todavía: cargar el documento Word con un editor hexadecimal y eliminar todos los bytes desde el principio del fichero hasta el comienzo de la cabecera GIF (es decir, justo antes de la cadena “GIF89a”). Parece que a los visores GIF no les importa demasiado que haya “porquería” al final del fichero o al menos al visor que utilizamos, que fue el de Windows.

El caso es que al abrir el fichero resultante con un visualizador adecuado (que contemple las animaciones del GIF), veremos una imagen animada (también de 443 x 50 y formada por 38 fotogramas). El último fotograma de la imagen es el que se muestra a continuación (el resto de fotogramas mostraba poco a poco la imagen con un efecto cortina de izquierda a derecha y no tenía más utilidad):


Mensaje en Braille
Si la propia imagen no nos dice nada ya de por sí sola, también teníamos una pista a nuestra disposición, ya que el fragmento de la imagen en el fichero binario iba precedido del texto “braile” (lo que probablemente se correspondería con el nombre del fichero original). Efectivamente, se trata de un texto codificado en Braille, el conocidísimo alfabeto de los ciegos, así que para averiguar lo que está escrito no tenemos más que comparar los signos con los de cualquier tabla de referencia de dicho alfabeto, teniendo en cuenta que cada signo está formado por una matriz de tres filas y dos columnas de puntos (presentes o ausentes):


Alfabeto Braille
Si utilizamos como referencia cualquiera de las tablas que aparecen en las primeras posiciones de cualquier buscador, veremos que van saliendo la mayoría de los símbolos y es fácil intuir que se trata de una URL, por lo que podemos ir deduciendo algunos de ellos muy fácilmente (como los dos puntos y las barras), pero hay otros que no encontramos por ningún sitio y la cosa se complica un poco:

http://retohackingx.elladodelmal.com

/?r?t?????????????solved/theend.aspx
Todo parece indicar que ya estamos muy cerca del final, pero aún nos falta un buen trozo de la URL y tendremos que encontrar los símbolos que nos faltan, o intentar deducirlos, ya que algunos de ellos se repiten y puede que eso nos permita encontrar algún patrón o pista para intuir alguna palabra.

La verdad es que en el caso de Dani se tuvo la suerte de encontrar una tipografía (fuente o tipo de letra) que contenía exactamente todos los símbolos restantes y ayudándose del mapa de caracteres de Windows los fue sacando cómodamente. Bueno, al decir que tuvo suerte tampoco queremos decir que lo encontrara en cuestión de segundos, porque estuvo un buen rato buscando y no encontró nada útil hasta que pensó que tal vez existiera algún tipo de Braille adaptado al mundo de la informática y buscó la cadena “Unicode Braille” en Google, encontrando entre los primeros 5 resultados una página web con diferentes ficheros TTF de tipografías de Braille descargables desde ahí mismo y probó con la primera de las que aparecían, resultando ser perfectamente válida y adecuada para esta fase del reto.

En cualquier caso, de no haber encontrado la tipografía exacta, podíamos haber aplicado un proceso deductivo, basándonos en las dos letras que habíamos logrado decodificar y en el símbolo de la fila de tres puntos a la derecha, que tenía pinta de ser algún tipo de separador, así como del símbolo que más se repetía (el de los tres puntos representando una especie de esquina inferior derecha).


|r_t*|_*|_**_|*_|solved
Si logramos intuir que la primera palabra era “reto”, escrita al más puro estilo hacker (“r3t0”), ya tenemos un paso importante, puesto que ahora podremos reemplazar el símbolo del asterisco por ese cero que acabamos de encontrar y tal vez podamos asumir que todos los símbolos restantes fueran dígitos y lanzar un pequeño ataque de fuerza bruta, aunque si seguimos con la racha de contextualizar más aún la URL, podemos intuir que el segundo bloque es un 10 (recordemos que estamos ante el décimo reto) y que el siguiente se corresponde con la fecha (año y mes). De todas formas, aún no hemos dado con el carácter separador, pero eso ya os lo dejamos como ejercicio si os apetece intentarlo... ;-)

El razonamiento de Román fue similar. Él no tuvo la suerte de encontrar el TTF adecuado pero viendo que faltaban los números y comparando las agrupaciones de puntos que faltaban por resolver con una tabla Braille se podía observar que los puntos estaban incorrectamente trasladados una fila hacia abajo y que tampoco se había utilizado el símbolo especial para designar números. Deshaciendo el “shift” anterior era trivial obtener los caracteres numéricos restantes y con éstos el separador también era fácil de adivinar.

Tal vez más de uno se extrañe de ver esa representación tan peculiar de los dígitos en Braile, puesto que lo normal (tal y como aparece en la inmensa mayoría de referencias y como estamos acostumbrados a ver en ascensores y otros lugares) sería prefijar con el símbolo de número (una L reflejada horizontalmente) las primeras letras del abecedario (a=1, b=2, c=3, etc). ¿Y por qué no se hizo así? Pues la verdad es que no tenemos ni idea, pero parece que alguno estaba empeñado en complicarnos las cosas con pequeños detalles cuya resolución lleva más tiempo del que parece. O simplemente se equivocaron (bien al traducir a mano o bien por utilizar un .ttf erróneo y arrastrando por tanto los fallos), que es la opción más probable.

En fin, tras este último paso termina el reto (queda resuelto de forma automática al acceder a la URL correcta):


Fin
Apareciendo nuestro nombre de usuario en el ansiado Hall of Fame y dándonos la satisfacción que ello conlleva.


Hall of Fame
Como curiosidad para terminar, añadir que ambos finalizamos el reto casi al mismo tiempo (y antes de las 24h del inicio del mismo) pero Román decidió no “firmar” hasta pasados tres días. La razón es que inicialmente él utilizó el XML obtenido con la herramienta de Dani para continuar con el resto de pruebas, puesto que el método del WebScarab era más lento así que posteriormente decidió compensar esa ventaja auto-penalizándose con tres días (que podrían haber sido muchos menos pero de alguna forma se quiso premiar y reconocer el trabajo de los que crearan su propia herramienta de Blind XPath Injection así como darle más emoción al reto).

Agradecimientos y comentarios

Suponemos que a nadie se le habrá escapado el detalle de que por primera vez ambos nos hemos aliado para resolver un reto de Informática 64, así como para redactar este documento. También nos gustaría conocer las impresiones, técnicas y trucos del resto de participantes, ya que no han sido pocos los que han resuelto el reto.

Quién sabe si la próxima vez volveremos a participar juntos o por separado, pero en cualquier caso ha sido una experiencia divertida y motivadora. De no haber sido así, seguramente nos habríamos aburrido mucho antes y no habríamos estado conectados hasta las tantas de la madrugada... ;-)

En fin, queremos terminar este documento agradeciéndole al equipo de I64 por la organización del reto y, sobre todo, al resto de participantes porque sin ellos los retos no tendrían sentido… Y cómo no, a Dreyer y Uri, dos de los más brillantes “Pwndas”.

Saludos,

Daniel Kachakil (dani@kachakil.com)
Román Medina-Heigl Hernández (roman@rs-labs.com)

PS: Puedes descargar el pdf con el solucionario completo de:

- http://www.rs-labs.com/papers/i64_reto_10.pdf
- http://www.kachakil.com/retos/I64_Reto_10.pdf

*****************************************************************************************
- Reto Hacking X: Solucionario (I de III)
- Reto Hacking X: Solucionario (II de III)
- Reto Hacking X: Solucionario (III de III)
*****************************************************************************************