WEB HACKING – Atacando DOJO Hacme Casino – Vulnerabilidad CSRF Parte XXVI

En el articulo anterior, ya teníamos acceso a la aplicación utilizando una cuenta de usuario valida, gracias a una vulnerabilidad de SQL Injection que permitía realizar un “ByPass” del mecanismo de autenticación implementado (login/password). Se trata de una vulnerabilidad que, aunque cada vez suele ser más rara de encontrar, sirve para demostrar lo que es una Blind SQL Injection en todo su esplendor…

En esta ocasión, aprovechando que ya se cuenta con acceso a la aplicación, se procederá a analizar las algunas peticiones HTTP de la aplicación para intentar detectar cualquier otra “brecha” que nos permita hacer más “daño”. Para ello, como el lector seguramente ya comprenderá, basta con utilizar un proxy web como por ejemplo Burp Proxy, OWASP Zap o incluso algún que otro plugin de Firefox que sirve, básicamente para lo mismo, como por ejemplo Tamper Data o Live HTTP Headers.

Independiente de la herramienta utilizada, una de las primeras cosas que llama la atención cuando estamos autenticados con el usuario “andy_aces” es que, en primer lugar no tiene suficiente dinero para jugar y en segundo lugar, hay una opción que resulta bastante llamativa en el enlace de “Options”, donde es posible transferir dinero entre jugadores o desde una cuenta bancaria ficticia. Desde luego, parece ser un buen lugar para investigar que parámetros viajan en la petición y ver si es posible conseguir algo de dinero para jugar (es una pena que no sea dinero real :P)

Es muy probable que aquí podamos encontrarnos con una CSRF (Cross Site Request Forgery) y realizar una transferencia de “Chips” desde un jugador en el sistema a nuestro usuario (andy_aces).

Para saber si nuestras sospechas son correctas, podemos hacer una prueba rápida utilizando solamente nuestro navegador web, en este caso Firefox y el Plugin Tamper Data pueden ser muy útiles.

Después de capturar una petición de “Transferencia de Chips” al usuario “Bobby Blackjack” nos encontramos con que los parámetros utilizados son:

transfer: Cantidad de Chips a transferir.

login[]: Usuario (o lista de usuarios) receptores de la transferencia.

commit: Tipo de acción a realizar (recordar que en el formulario también es posible realizar una hipotética transferencia desde una cuenta bancaria.

La siguiente imagen enseña la petición capturada desde el plugin Tamper Data (Notar que esto mismo se puede hacer desde un proxy web como Burp Suite, OWASP Zap o WebScarab, para gustos colores).

Que nos impide modificar el campo login[] para establecer cualquier usuario y posteriormente, enviar un enlace a dicha petición a un usuario valido? Nada.

Supongamos que el usuario bobby_blackjack se encuentra leyendo su correo y a la vez tiene iniciada una sesión en la aplicación vulnerable, además supongamos que le ha llegado un email bastante elaborado, indicando que debe pinchar sobre el siguiente enlace:

http://192.168.1.41:3000/account/transfer_chips?transfer=1000&login[]=andy_aces&commit=Transfer+Chips

Suponiendo que «192.168.1.33» fuera una IP pública valida, que pasaria? Simplemente que desde la cuenta de bobby_blackjack se realizará una transferencia de 1000 chips hacia el jugador andy_aces. Todo esto con simplemente por pinchar sobre un enlace.

Aunque seguramente al lector estas suposiciones le parezcan una “rareza” teórica, el hecho de que un usuario pinche sobre enlaces que se encuentran contenidos en mensajes de correo electrónico, actualmente es uno de los vectores de ataque más utilizados (y abusados) por atacantes en todo el mundo, ya que muchos de los usuarios que hay por ahí utilizando servicios de mensajería creen que no serán víctimas de ataques de phishing y suelen decir “Pero si yo no tengo nada en en internet, quien se va a molestar en atacarme”. Esos suelen ser los que menos se preocupan en pinchar sobre enlaces potencialmente peligrosos o de mantener sus credenciales debidamente actualizadas y con unas medidas de seguridad mínimas.

En fin, volviendo al tema, suponemos que puede haber una vulnerabilidad CSRF en el formulario de transferencia de Chips, sin embargo, de momento solo es una suposición. Para comprobarlo, podemos volver a utilizar la vulnerabilidad SQL Injection encontrada anteriormente con la que hemos podido acceder a la aplicación como andy_aces, solo que está vez, entraremos como bobby_blackjack tal como se enseña en la siguiente imagen:

Ahora tenemos acceso a la aplicación como bobby_blackjack (El cual, tiene suficientes Chips)

Ahora, manteniendo abierta la sesión de bobby_blackjack podemos abrir otra pestaña del navegador e introducir el enlace anterior (http://192.168.1.41:3000/account/transfer_chips?transfer=1000&login[]=andy_aces&commit=Transfer+Chips) para determinar si en realidad existe una vulnerabilidad CSRF en el formulario. Desde dicha pestaña, se abrirá el formulario correspondiente

Al parecer, ha habido una reducción de 1000 Chips en la cuenta de Bobby, lo que indica claramente, que el formulario es vulnerable. Si cerramos la sesión de bobby_blackjack y accedemos nuevamente como andy_aces podemos ver lo siguiente:

Como podemos ver, ahora el usuario Andy tiene suficientes Chips para jugar una partida…

En una próxima publicación, más ejemplos de vulnerabilidades en aplicaciones web con HacMe Casino.