WEB HACKING – Atacando DOJO Hacme Casino – Otras Vulnerabilidades Parte XXVII

Las dos vulnerabilidades que se han explicado anteriormente sobre HacMe Casino, permitían que cualquiera pudiera acceder y manipular de forma arbitraria, la información de otros usuarios en el sistema. En está ocasión se examinarán otras vulnerabilidades existentes en la aplicación para poder analizar su impacto.

Para empezar, no hemos visto aun el formulario de registro de usuarios, que permite crear cuentas en el sistema. Se trata de un formulario bastante simple, que solamente requiere como parámetros de entrada los campos correspondientes al nombre de usuario, contraseña y nombres y apellidos. Sin embargo, del mismo modo que ocurre con el formulario de login, del que se ha hablado anteriormente, es posible que este formulario sea vulnerable a SQL Injection y a otro tipo de vulnerabilidad muy grave, XSS Almacenado. Para comprobarlo, basta con intentar ingresar datos en el formulario que probablemente puedan ser maliciosos, tal como enseña la siguiente imagen:

Después de pinchar sobre el botón de registro, con los datos introducidos anteriormente, podemos ver la siguiente respuesta por parte del servidor:

Se ha producido una excepción con la siguiente traza:

SQLite3::SQLException: unrecognized token: "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8": SELECT * FROM users WHERE (login = 'user'' AND password = '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8')  LIMIT 1

Del mensaje anterior se puede extraer, que posiblemente se intenta realizar una consulta para determinar si el login del usuario se encuentra registrado actualmente en el sistema. Esto es bastante común en los formularios de registro en aplicaciones web, con el fin de mantener la consistencia en los datos y no permitir usuarios duplicados.

Aquí nuevamente nos encontramos con una vulnerabilidad SQL Injection sin embargo, en este caso, la aplicación nos da un informe claro, indicando la causa del fallo. Este caso hablamos de una vulnerabilidad SQL Injection informada, mientras que en el caso del formulario de login, del que se ha hablado en artículos anteriores, hablábamos de una vulnerabilidad SQL Injection Ciega. La diferencia resulta bastante obvia, está en la cantidad de información que el sistema nos entrega cuando se produce el fallo, si el sistema nos enseña una traza de error, es fácil determinar que existe una vulnerabilidad simplemente analizando el error, en caso contrario, es necesario realizar pruebas y determinar si con un conjunto de datos ingresados se produce algún tipo de cambio en el comportamiento de la aplicación (proceso formalmente conocido como Fuzzing). vamos “a ciegas”, por eso se les conoce como Blind SQL Injection.

Independiente de la categoría de esta vulnerabilidad, el efecto sigue siendo el mismo, se puede ingresar al sistema haciendo un bypass del mecanismo de autenticación tal como enseña las siguientes imágenes:

Entender la lógica de la aplicación

Algo que no debemos olvidar nunca, es que las aplicaciones web, normalmente son desarrolladas con fines muy concretos y que a veces, las funcionalidades desarrolladas, no son debidamente probadas y en algunos casos, permiten que sus usuarios puedan hacer cosas que en principio, el sistema no debería permitir. En el caso de HacMe Casino, el fin de la aplicación es claro: Permitir que los usuarios puedan entretenerse con juegos de azar. No obstante las validaciones lógicas que se deberían aplicar no son el fuerte en esta aplicación y si se tratará una aplicación montada en un casino real, la clásica frase de “La casa siempre gana” no seria aplicable en lo absoluto.

Por ejemplo, en un casino real, cuando comienzas un juego, no puedes retirarte en la mitad de la partida simplemente porque no te gustan las cartas que te han tocado e irte con tu dinero intacto, pues en el juego de BlackJack de HacMe Casino, se puede hacer. Este es un claro ejemplo de fallos lógicos a nivel de aplicación ya que ningún jugador debería poder abandonar una partida que ha iniciado y terminar con sus fichas intactas.

Por ejemplo, la siguiente imagen, enseña como después de hacer una apuesta de 13 chips, el jugador puede simplemente pinchar sobre el enlace del menú lateral en cualquiera de las opciones y sin que la aplicación le obligue a terminar primero su partida, con lo cual, si las cartas que hay sobre el tablero no le agradan, pues simplemente vuelve al lobby y aquí no ha pasado nada. Un jugador podría repetir este mismo procedimiento N veces esperando a una buena mano y ganar en casi todas las partidas.

Ahora bien, este es un caso muy concreto para esta aplicación concreta, ahí afuera hay muchas aplicaciones web que tienen errores lógicos muy graves que permiten que un atacante haga de las suyas sin prácticamente ninguna limitación y así mismo, cada aplicación es un mundo y un buen atacante o pentester necesita en todos los casos, algo en lo que he insistido mucho en este blog: Creatividad y Persistencia esas virtudes son muy importantes para poder detectar y explotar adecuadamente este tipo de errores, que como el lector comprenderá, suelen ser difíciles de encontrar y de explotar.

Ganar Siempre

Desde luego, lo que más nos interesa cuando jugamos es ganar y si lo podemos hacer siempre, pues mucho mejor! Cuando analizamos las peticiones que se realizan en el juego de BlackJack utilizando Burp Proxy o algún plugin del navegador web, es posible darse cuenta de que cada una de las peticiones que se llevan a cabo contra el servidor, se realizan de forma asíncrona utilizando Ajax. Actualmente es bastante común encontrar aplicaciones que intentan brindar un diseño mucho más fluido y con una mejor interacción con el usuario por medio del uso de estas tecnologías y también, es cada vez más común, que los atacantes analicen con todo lujo de detalles, la interacción entre cliente y servidor con el fin de encontrar algún agujero por donde colarse. En el caso del juego previamente mencionado, podemos darnos cuenta de que existen dos opciones antes de terminar cada apuesta, dichas opciones son Hit y Stay. Cuando pulsamos sobre Hit vemos se realiza una petición al recurso: /blackjack/hit_or_stay utilizando como parámetro act=H y cuando pulsamos sobre Stay se realiza una petición al mismo recurso utilizando el parámetro act=S. De momento, no hay nada novedoso en todo esto, sin embargo, si estamos utilizando Burp Proxy, ZAP, Paros, o cualquier otro proxy web para interceptar las peticiones, podemos repetirlas realizando las modificaciones que nos resulten convenientes (o no realizar ninguna modificación en lo absoluto).

En este caso, podemos capturar las peticiones y esperar a que en alguna de las partidas, el jugador gane alguna de las apuestas, como se enseña en la siguiente imagen:

El jugador tiene solo 387 chips y ha ganado 1, sin embargo, si hemos capturado dicha petición utilizando Burp Proxy y podríamos repetirla nuevamente y ver que pasa…

Cada vez que repetimos la misma petición el servidor retorna siempre la misma respuesta, lo que aparentemente parece el procesamiento repetido de la partida. Vamos a repetir la misma petición unas cuantas veces y posteriormente vamos a volver a la cuenta de usuario donde se pueden apreciar los fichas que tiene actualmente.

Ahora tiene muchas más que antes de comenzar la partida en la que solamente debió ganar 1 ficha. Que es lo que ha pasado? Sencillamente, el servidor web no ha validado correctamente las peticiones y ha recalculado nuevamente las cartas para determinar si el jugador había ganado o perdido en el juego y posteriormente ha sumado la cantidad de fichas apostadas. Dado que hemos repetido N veces la misma petición en la que el jugador apostaba y ganaba una ficha, el servidor ha realizado el procesamiento N veces, sumando N fichas a la cuenta del jugador.

Este es un error lógico, que en la practica es más común de lo que parece, por ejemplo, cuantas veces nos hemos encontrado con que después de hacer “submit” sobre un formulario web en alguna aplicación en internet, pulsamos el botón “ Atrás” del navegador y después de volver a sumitir la página, el servidor parece realizar exactamente la misma operación, asumiendo que se trata de una petición distinta a la anterior, sin validar la consistencia e integridad de los datos? Creo que a todos en alguna ocasión nos ha pasado algo parecido y a diferencia del ejemplo anterior con el juego de BlackJack, a veces el resultado puede no ser tan agradable, por ejemplo, realizando compras online… lo mismo podría ocurrir en una aplicación mal diseñada y con problemas de consistencia de datos, donde nos pueden cobrar 2 veces (o más) por el mismo producto, simplemente porque la aplicación web no maneja de forma consistente las peticiones realizadas por sus clientes. Creo que ya habéis comprendido lo que quiero decir 🙂

Esto es todo por ahora, en la próxima publicación, un poco más sobre HacMe Casino y ejemplos prácticos de seguridad en aplicaciones web.