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

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

Enero 2008 © Daniel Kachakil


Introducción

se publicó el 14 de diciembre de 2007 en la siguiente dirección web:


Este documento describe una solución al Reto Hacking V de Informática 64 que

http://retohacking5.elladodelmal.com






Pistas

Unas horas antes del comienzo del reto se publicaron las pistas en este post.
Como comentario personal, si alguien fue capaz de intuir algo útil partiendo de estas
pistas, aparte de felicitarle por ello, yo le recomendaría que acudiera a un especialista
para que le trate el enredo neuronal que pudiera tener. Otra cosa es que se pueda tratar
de justificar el texto de cada pista después de haber dado con la solución, pero no es el
caso. Como a mí no me resultaron de ninguna utilidad (más bien al contario, alguna me
confundió un poco), mejor vayamos directamente a la resolución del reto.


Parte 1: Las tres preguntas

Tras registrarnos rellenando el formulario de alta y validarnos con los datos de
acceso elegidos, accedemos a la primera fase del reto. Lo primero que observamos es
que el uso de Adobe Flash es evidente, por lo que en casos como este nunca está de más
tener a mano un descompilador (por si acaso, aunque su uso no era imprescindible).

1

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



© Daniel Kachakil

La primera fase consistía en responder correctamente a tres preguntas
consecutivas. Viendo el número de respuestas posibles, la probabilidad de pasar esa fase
mediante prueba y error era demasiado baja y no parecía el método más razonable, por
lo que analizamos el tráfico HTTP que está generando el Flash para detectar posibles
vulnerabilidades. Esto lo podemos lograr de varias formas: por ingeniería inversa
(examinando el código descompilado del Flash), intercalando un proxy (por ejemplo,
Odysseus) o capturando paquetes de nuestra propia interfaz de red (localizando las
peticiones GET y POST).


Veamos algunas peticiones realizadas (Px) junto con sus respectivas respuestas

por parte del servidor (Rx) y la descripción o comentarios al respecto (Cx):


http://retohacking5.elladodelmal.com/Privado/ObtenerDatos.aspx?tipo=numrespuestas&rand=123.45678
contenido=3

P1
R1
C1 Número que aparece en la frase "Eres el pringao número X que lo intenta"
P2
R2
C2
P3
R3

http://retohacking5.elladodelmal.com/Privado/ObtenerDatos.aspx?tipo=pregunta&rand=123.4567890
contenido=¿Para que quiere un pastor un compilador?
Texto de la pregunta actual
http://retohacking5.elladodelmal.com/Privado/ObtenerDatos.aspx?tipo=respuesta&rand=1234
contenido=276;Creo que he visto un mono de tres cabezas;El rabino de tu hermana!;El caracol verde;Ha sido
él!;Joder, no entiendo nada;La vida es bella, no te hagas preguntas existenciales;La culpa es del gobierno;La casa por
el tejado;Me humillo ante ti, ¿y me faltas al respeto?;Me estas vacilando, y tengo unas ganas de darte dos host...;No
hablo tu idioma;No;No se si he visto un mono de una cabezas;Pa orejas las de mi suegra;Por el culo te la
hinco!;Rumenigue;Sí, claro y también me agacho a por el jabón;Sí;Saca de ahí la cabeza;jaja... muy buena...
úñaaao!!!;mmmm... estoy pensando... mmmm;¡3 con las que saques!;¿Y a ti que más te da? ¿Nos fumamos
algo?;¿Qué?, no consigo entenderte;¿Donde dices?;¿Eso viene en educación para la ciudadanía?;¿Qué quieres que te
diga?, el glamour;¿No lo sabes? ... paleto!;Úbuntu;
Texto de las respuestas posibles, separadas por punto y coma
http://retohacking5.elladodelmal.com/Privado/ObtenerDatos.aspx?tipo=crespuesta&datos=276&rand=12
contenido=0
El servidor comprueba si la respuesta a la pregunta es correcta. Devuelve 0 en caso de haber fallado.

C3
P4
R4
C4



Las respuestas mostradas son un ejemplo de un caso concreto. Lo primero que
observamos es que cada vez que se realiza una nueva petición, aunque tenga
exactamente los mismos parámetros, es muy probable que la respuesta del servidor sea
completamente diferente y sin relación aparente con la anterior, debido a que el código
del servidor utiliza una secuencia aleatoria independiente de los parámetros. Todas las
respuestas parecen ser completamente independientes del parámetro "rand", cuya única
utilidad seguramente sea la de evitar los inconvenientes que podrían tener los
mecanismos de caché con el Flash ejecutándose en el lado cliente, por lo que podremos
prescindir de dicho parámetro en el resto de nuestras pruebas.


Tras realizar un par de pruebas de manipulación de parámetros sin éxito, pensé
que si fijaba una de las respuestas posibles y repetía la comprobación de la respuesta
realizando peticiones sucesivas, al final terminaría acertando la primera pregunta y el
servidor me debería devolver como respuesta "contenido=1" y, efectivamente, así fue.
Me extrañó que al volver a repetir dicha petición (P4) una y otra vez, ese valor nunca
volvió a valer cero (incluso llegó a valer 2), así que supuse que la vulnerabilidad de esta
primera fase tenía que estar basada en haber implementado una funcionalidad
importante en el lado cliente, cuando debería haberse implementado en el servidor.


Un programador podría asumir que las llamadas a sus procedimientos se
realizarán siempre en el orden en el que las programó, por lo que no sería tan extraño
pensar que el fragmento de código que resetea el número de aciertos esté en el método
que obtiene las respuestas y que a su vez este método sea invocado siempre que se falle



2

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



© Daniel Kachakil

alguna respuesta. En teoría dicho código sería perfectamente funcional y válido, pero
tiene un problema potencial bastante grave. Al igual que ocurre con JavaScript o
VBScript, por ejemplo, el código que ejecuta Flash es una secuencia de acciones que
puede ser usada para implementar parte de la lógica de la aplicación global. El problema
aparece porque, a diferencia de la lógica implementada en la parte del servidor, la que
se ejecuta en el lado cliente es susceptible de ser manipulada con relativa facilidad.

A los pocos minutos de haber comenzado el reto y de haber realizado estas

pruebas tan sencillas, comprobamos que la respuesta final es "contenido=2", pero aún
no sabemos cómo pasar a la siguiente fase. Si descompilamos el Flash, observamos que
la última acción que realiza el código es la de redirigirnos de nuevo a la misma página
"Nivel1.aspx". Como el servidor almacena la fase en la que estamos de forma
permanente, también podríamos haber superado la fase sin más que volver a
autentificarnos. Superar esta fase era así de sencillo (repetir P4 unas cuantas veces).


Parte 2: Dolor de espalda

En esta fase aparecemos al lado de una enorme cabeza de mono, en la que se
observa una inscripción en uno de sus dientes. Pulsando sobre ese diente nos aparece un
texto ininteligible, indicándonos que parece estar en cirílico.


Evidentemente no se trataba de cirílico (porque dicho alfabeto sería distinguible
a simple vista), sino de uno de los cifrados más simples que nos podemos encontrar: el
cifrado César, que se usaba ya desde hace más de 2.000 años, consistente en desplazar
el alfabeto completo N posiciones, es decir, sustituir cada letra por la que está N
posiciones a la derecha de la misma. En este tipo de cifrado no vale la pena realizar
ningún tipo de criptoanálisis, ya que siempre acabaremos antes probando todas las
posibilidades (25, excluyendo la "ñ"). El algoritmo es tan sencillo que no nos costará
encontrarlo implementado online en alguna web como esta, en la que descifraremos el
mensaje poniendo como clave "D" (es decir, N=3 posiciones).






Ahora que tenemos el texto en claro, comprobamos que se trata de una simple

pista y que con esto no es suficiente para pasar a la siguiente fase, por lo que tendremos
que seguir buscando. De todas formas, la pista nos lleva a pensar que nuestro objetivo
es el de conseguir algún fichero con un mapa en la carpeta "c:\recursos".


Semanas antes de comenzar el reto, estaba leyendo la PCWorld de noviembre
cuando me encontré con un artículo, que me resultó bastante curioso, sobre la
extracción de ficheros usando técnicas de Blind SQL Injection. La técnica que describía
el artículo era tan explícita y fácil de implementar que dudé bastante si esa parte podría
aparecer en el reto después de haber sido publicada su solución. El coste de
implementar una herramienta para SQL Server 2005 era tan bajo que no dudé en hacerla
en su día y comprobar que el método funcionaba perfectamente. El autor colgó en su
blog un post con dicha parte del artículo pocos días después de haber comenzado el reto
(por cierto, casualmente, el autor del artículo es Chema Alonso)

ho pdsd txh wh oohydud d uhvroyhu ho sxcoh vh hqfxhqwud hq od fdushwd
el mapa que te llevara a resolver el puzle se encuentra en la carpeta
uhfxuvrv gh od xqlgdg sulqflsdo
recursos de la unidad principal



3

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



© Daniel Kachakil



Habiendo implementado ya la herramienta, el único paso que nos falta para
extraer un fichero es localizar una vulnerabilidad de Blind SQL Injection. En la escena
de la cabeza del mono aparecen varios objetos que podemos ir pulsando, aunque
siempre obtendremos la misma respuesta: "No pienso agacharme a coger ese objeto". A
nivel interno, comprobamos que este mensaje se obtiene tras realizar una petición por
HTTP como la que se muestra en la siguiente URL:




Para comprobar si ese parámetro es vulnerable, simplemente le inyectaremos
una condición que sepamos que siempre es verdadera (and 1=1), verificando que la
respuesta no varía. A continuación debemo