Ataques Web - Demostración - Fuerza Bruta

Navegando por Internet es frecuente encontrar sitios web con formularios de acceso o autenticación que no incorporan sistemas captcha para evitar los ataques por fuerza bruta. 

Para explotar esta vulnerabilidad de DVWA se hará uso de dos aplicaciones diferentes: Burp Suite Free Edition (versión 1.4.01) e Hydra.

En primer lugar se configurará el explorador web para que se conecte a través de un proxy HTTP en la dirección 127.0.0.1 (localhost) en el puerto 8080 y se lanzará la aplicación Burp Suite Free Edition que automáticamente inicia la herramienta proxy encargada de interceptar todas las peticiones web en dicho puerto.

Una vez realizada esta configuración, se accede al formulario web en el que se solicitan los datos de autenticación y se procede a enviar el formulario. En este punto es irrelevante que no se conozcan los datos de acceso puesto que sólo se pretenden capturar la petición HTTP GET realizada para la autenticación, la cookie con el identificador de sesión y el mensaje (si lo hubiera) devuelto por el sistema en caso de que el nombre de usuario y/o contraseña sean incorrectos.

En este caso el mensaje recibido ha sido “Username and/or password incorrect” y como se aprecia en la siguiente figura, la herramienta proxy de Burp Suite ha interceptado la petición HTTP GET con los otros tres parámetros comentados con anterioridad.

A continuación se enviarán estos datos a la herramienta intruder, encargada de llevar a cabo el ataque por fuerza bruta.

En la pestaña target se observa el host de destino al que se realizarán las peticiones HTTP GET simulando el acceso a través del formulario web así como el puerto (el 80, correspondiente a web).

En la pestaña positions se seleccionará el tipo de ataque y los campos (marcados con el símbolo §) que se quieran obtener. Los campos corresponden al nombre de usuario y la contraseña y el tipo de ataque seleccionado será “cluster bomb”, consistente en la prueba de todos los valores de un parámetro contra todas las posibles combinaciones de valores del resto.

La selección del payload dependerá del tipo de dato que se quiera utilizar. Las opciones que ofrece la herramienta intruder son amplias: desde la carga de diccionarios, hasta la selección de caracteres para efectuar una fuerza bruta clásica, pasando por fechas o generador en base a una cadena dada. Además, pueden realizarse operaciones sobre los datos seleccionados, como codificación en Base64 o aplicación de funciones hash.

En este ejemplo el primer payload (correspondiente al nombre de usuario) será un listado con las palabras “admin”, “administrador” y “administrator”.

Por su parte, el payload correspondiente a la contraseña será el contenido de un diccionario compuesto únicamente por 156 cadenas de caracteres.

Una vez seleccionados ambos payloads, se inicia el ataque haciendo clic en la opción “Start attack” del menú “Intruder”.

La herramienta intruder nos permite examinar la respuesta del servidor para la petición de autenticación con cada par de payloads.

Después de un largo tiempo de espera (por el mencionado retraso en las peticiones en la versión gratuita) se aprecia que para el par “admin”, “password” el tamaño de la respuesta es diferente. Al examinar con más detalle el código fuente HTML servido se observa que en lugar del mensaje “Username and/or password incorrect.” el servidor ha devuelto “Welcome to the password protected area admin”.

Así pues este ataque por fuerza bruta combinado con el de diccionario ha dado sus frutos y los datos de acceso a la web son “admin” como nombre de usuario y “password” como contraseña.

Prevención

En el nivel de seguridad high se ha implementado el uso de la función sleep() de PHP.

Esta función ha provocado que se hayan producido 4 falsos positivos dejando el ataque sin efecto.

Sin embargo y a pesar de que la función sleep() se ha mostrado efectiva en este caso, para prevenir este tipo de ataques se recomienda el uso de un sistema de captcha, ya sea desde el primer intento o después de un determinado número de intentos fallidos, así como bloquear las peticiones recibidas desde aquellas IPs que hayan cometido un número de intentos fallidos en un determinado espacio de tiempo.

Puesto que estas pautas no tienen por qué ser aún suficientes, adicionalmente se recomienda el uso de tokens aleatorios en los formularios. Se verá un ejemplo de esta práctica en la vulnerabilidad CSRF.