Hoy en día, la mayoría de aplicaciones web cuenta con medidas de autenticación multi-factor (MFA), como por ejemplo el envío de un código a tu teléfono móvil. Si bien estas medidas pueden llegar a ser muy efectivas para defendernos ante ataques de fuerza bruta o una filtración de credenciales, si no se implementan correctamente pueden ser completamente inútiles. En esta sección veremos algunos ejemplos de malas implementaciones de sistemas de autenticación multi-factor.

1. Bypass simple de MFA

Uno de los ejemplos más simples de una mala implementación de un sistema de autenticación multi-factor es aquel en el que podemos saltarnos directamente esta verificación. Imagina el siguiente escenario.

1. Tenemos una aplicación web con un formulario de autenticación que solicita las credenciales del usuario.
2. Si las credenciales son correctas, el servidor nos devuelve un token de sesión y nos redirige a una pantalla para ingresar un código enviado a nuestro teléfono.
3. Si el código es correcto, nos redirige a /dashboard, si es incorrecto, invalida nuestro token de sesión y nos redirige a /login.

En este escenario de ejemplo encontramos una falla muy grave en la implementación, y es que cuando ingresamos unas credenciales válidas, ya se nos otorga un token de sesión válido que solo se invalida si enviamos un código de verificación incorrecto. En este punto, saltarnos validación del código resulta trivial. Bastaría con hacer lo siguiente:

1. Autenticarnos con unas credenciales válidas.
2. El servidor nos redirige a la página para ingresar el código.
3. En lugar de ingresar el código (lo cual invalidaría nuestra sesión porque no lo sabemos), navegamos a /dashboard directamente. Como nuestro token de sesión es válido y no se ha invalidado porque no hemos ingresado ningún código incorrecto, podríamos acceder al dashboard del usuario como si hubiéramos iniciado sesión correctamente.

2. Bypass de MFA por fuerza bruta

Uno de los métodos más habituales de implementar MFA es mediante el envío de códigos numéricos de 4 dígitos enviados a nuestro teléfono. El problema de estos códigos es la cantidad de combinaciones posibles, “tan solo” 9999 posibilidades. Sin un mecanisamo de prevención de ataques de fuerza bruta (un rate-limit), encontrar la combinación correcta resultaría trivial.

Supongamos el escenario en el que hemos ingresado unas credenciales válidas y se nos ha redirigido a una página para ingresar un código de 4 dígitos enviado a nuestro teléfono. El servidor no tiene ningún sistema de rate-limit ni cancela el proceso si se introduce de forma incorrecta múltiples veces. Un simple script que envíe múltiples solicitudes hasta encontrar el código correcto sería tan trivial como realizar algo similar al siguiente código. Supondremos que si ingresamos un código correcto seremos redirigidos (código 302), pero en caso contrario permanecemos en la página recibiendo un código 200.

# Creamos la lista de números de 0000 a 9999, para agregar ceros a la izquierda usamos -w
seq -w 0000 9999 > codes.txt

# Usamos la wordlist anterior para enviar todas las combinaciones de código posibles
ffuf -X POST -u http://10.10.10.10/login-verify \
  -H "Cookie: verify=pepe" \
  -d "mfa-code=FUZZ" \
  -w codes.txt \
  -mc 302

NOTA: Siempre debes analizar el tipo de request que realiza la web, ya que es posible que se pasen parámetros adicionales, como un token csrf, o que los parámetros se pasen de forma distinta.

3. Bypass de MFA con tokens no vinculados a la sesión

Algunos sitios web pueden no vincular el token de verificación a la sesisón a la que se intenta acceder. Simplemente generan un token y lo registran en una base de datos de tokens válidos hasta que son utilizados y entonces se eliminan. Este mecanismo defectuoso puede permitir a un atacante conseguir un token iniciando sesión con su cuenta de usuario, pero usarlo en el inicio de sesión de otro usuario. Veamos el procedimiento.

1. El atacante con las credenciales de pepe inicia sesión en su cuenta.
2. El servidor redirige a una página para ingresar el token de verificiación que se envió a su correo.
3. El atacanta inicia sesión en su cuenta en una ventana aparte.
4. El servidor le redirige a la página para ingresar el token de verificación que se envió al email del atacante.
5. El atacante usa el token que le han enviado a su email para ingresarlo en el proceso de autenticación de pepe.
6. Si el servidor no vincula el token a la sesión, el servidor aceptará el token del atacante en el inicio de sesión de pepe.

4. Bypass de MFA con tokens predecibles

Algunas otras webs deciden implementar medidas propietarias de verificación en lugar de utilizar librerías estándar y bien probadas. En estos casos podemos llegar a encontrarnos situaciones como las siguientes:

• Tokens encodeados en base64 que al decodearlo en plataformas como CyberChef nos permitirán conocer la estructura de los mismos y generar nuestros propios tokens válidos.
• Tokens que utilizan cifrado débil que pueden ser crackeados y nos permitirán de nuevo conocer el la estructura de los tokens y generar los nuestros propios.
• Tokens generados aleatoriamente que no emplean algoritmos criptográficamente aleatorios. Mediante técnicas basadas en condiciones de carrera (por mencionar un ejemplo), podríamos tratar de generar un token de forma simultánea con una cuenta bajo nuestra posesión y otro con la cuenta a explotar. Si se generan en el mismo instante de tiempo entonces recibiremos el mismo token que se envió al usuario de la cuenta a explotar, lo que nos permitirá usar el token que recibimos en nuestro email para bypassear el MFA del usuario.