lunes, 9 de enero de 2012

Crackeando un Hash Cracker (I): XSS con MD5

Contribución de Julio Gómez: Empezamos el año con una contribución de Julio Gómez, compañero mio en el departamento de auditoría de S21sec y redactor del blog "La X Marca el Lugar" junto con otros compañeros. En su colaboración, va a destripar una de estas webs que ofrecen la posibilidad de introducirles un hash y que te devuelven su contraseña, que como veremos sufre algunos problemillas de seguridad, algo que no deja de ser gracioso teniendo en cuenta su función:

Cada vez es más habitual que la seguridad sea una característica a tener en cuenta durante los desarrollos de cualquier tipo de software. Dentro del ámbito de las aplicaciones web, es muy frecuente que los desarrolladores estén familiarizados con los términos Cross Site Scripting o Inyección de Código SQL. El problema es que, en muchos casos, no terminan de comprender del todo los diferentes tipos de vulnerabilidades y se conforman con seguir algún manual de buenas prácticas.

Éste es el caso de una aplicación web que recientemente me he encontrado en Internet y con la que no tengo nada que ver aunque haya gente que piense que está relacionada con una herramienta (findmyhash) que publiqué durante 2011.

La aplicación es un muy simple. Tan sólo tiene un formulario en el que se puede introducir un hash de cualquiera de los tipos soportados. Tras hacerlo, la aplicación parece que busca en varios servicios públicos de Internet el hash para tratar de recuperar el valor de la cadena que genera dicho hash.


Jugando un poco con la aplicación, intentando probar si es vulnerable a Cross Site Scripting, se puede comprobar que parece que filtra correctamente las entradas.

Cuando por mi profesión tengo que recomendar cómo prevenir los Cross Site Scripting en una aplicación web, siempre recomiendo que por un lado se validen todas las entradas de la aplicación y que, además, los valores dinámicos que se generen sean codificados utilizando HTML entities.

En la práctica, la realidad es que tan sólo se suelen validar las entradas que provengan directamente del usuario y no en todos los casos los desarrolladores se acuerdan de codificar las salidas. En el caso de esta aplicación en cuestión, las entradas de usuario están convenientemente validadas y codificadas, pero ¿y las salidas?

Partiendo de la base de que "no sabemos" (luego veremos que sí) cómo funciona la aplicación a nivel interno. Si seguimos trasteando vemos que nos devuelve si ha sido o no capaz de romper el hash y, de hacerlo, nos indica la cadena original que genera dicho hash.

No sé si ya habréis intuido por dónde voy... Las entradas se validan correctamente, pero ¿y si introducimos un hash que se corresponda con alguna cadena HTML? ¿Estarán codificando también la salida de la aplicación?

Si probamos a introducir hashes correspondientes a cadenas de inyección típicas (<script>alert("XSS")</script>) vemos que directamente la aplicación no es capaz de romperlas. Que por otro lado tiene sentido porque este tipo de aplicaciones suelen utilizarse para romper contraseñas y ¿quién utiliza como contraseña un vector de inyección para XSS? (que por otro lado sería una contraseña bastante buena...)

No obstante, como en la respuesta de la aplicación nos muestra algunos de los servicios que utiliza, al cabo de un rato de investigar encontramos uno que nos permite no sólo romper un hash, sino calcular uno nuevo a partir de una cadena. De este modo, se queda almacenada en su base de datos la cadena original y el hash asociado.


Para el ejemplo, he utilizado la cadena:
<iframe src="http://www.bing.com" style="position:absolute;z-index:200;display:inline;"></iframe>
cuyo MD5 es:
e8de8366340de0d9bda9858e97b42573
Si ahora probamos a introducir este MD5 en el buscador... ¡Bingo! La aplicación no codifica las salidas correctamente. Tenemos un Cross Site Scripting en toda regla, aunque algo rebuscado y de poca utilidad en un caso real.


Ahora que hemos conseguido realizar un XSS de esta forma un tanto alternativa, podemos irnos a probar otro tipo de vulnerabilidades en la página. Pero eso en el post de mañana.

3 comentarios :

Gabriel Pozo dijo...

Me gusto la manera que trabajaste la busqueda de la vulnerabilidad, la verdad que muy bueno.

Zion3R dijo...

ajjajaja, la verdad un tanto rebuscado, pero bueno ;)

Jose Selvi dijo...

Cierto, un tanto rebuscado, pero funciona ¿verdad?

Es una demostración de que una entrada da datos a veces puede ser alterada, aunque no sea directamente manipulable por el usuario.

En este caso el usuario puede forzar la modificación a través de un tercero :)