CSRF Lab 2

Skills

• CSRF where token validation depends on request method

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio es vulnerable a un ataque CSRF en la funcionalidad de cambio de correo electrónico. La web intenta bloquear los ataques CSRF, pero solo aplica contramedidas a ciertos tipos de solicitudes. Para resolver este laboratorio, debemos usar nuestro servidor de explotación para alojar una página HTML que lleve a cabo un ataque CSRF para cambiar la dirección de correo electrónico del usuario que visualice el mensaje. Podemos iniciar sesión en nuestra propia cuenta utilizando las credenciales wiener:peter

---

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

Para resolver el laboratorio, debemos explotar un CSRF, el cual es una vulnerabilidad de seguridad web que permite a un atacante inducir a los usuarios a realizar acciones que no tienen intención de realizar. Permite a un atacante eludir parcialmente la política de same origin, que está diseñada para evitar que diferentes sitios web interfieran entre sí. Para que sea posible un ataque CSRF, deben cumplirse tres condiciones clave

• Una acción relevante - Hay una acción dentro de la aplicación que el atacante tiene motivos para inducir. Puede ser una acción privilegiada (como modificar los permisos de otros usuarios) o cualquier acción sobre datos específicos del usuario (como cambiar la contraseña del usuario)

• Manejo de sesiones basado en cookies - Para realizar la acción, se deben emitir una o más solicitudes HTTP, y la aplicación se basa únicamente en las cookies de sesión para identificar al usuario que realizó las solicitudes. No existe ningún otro mecanismo para realizar el seguimiento de las sesiones o validar las solicitudes de los usuarios

• Sin parámetros de solicitud impredecibles - Las solicitudes que realizan la acción no contienen ningún parámetro cuyos valores el atacante no pueda determinar o adivinar. Por ejemplo, al hacer que un usuario cambie su contraseña, la función no es vulnerable si un atacante necesita saber el valor de la contraseña existente

Las defensas más comunes contra ataques CSRF con las que nos podemos encontrar son las siguientes

• Token CSRF - Es un token único, secreto e impredecible generado por el servidor y compartido con el cliente. Para realizar una acción sensible, como enviar un formulario, el cliente debe incluir este token. Esto dificulta que un atacante genere solicitudes válidas en nombre de la víctima

• Cookies SameSite - SameSite es un mecanismo de seguridad del navegador que regula cuándo se incluyen las cookies en las solicitudes de otros sitios web. Dado que las solicitudes para realizar acciones sensibles suelen requerir una cookie válida, es decir, una cookie que haya sido asignada tras una autenticación válida, las restricciones que aplica SameSite pueden impedir que un atacante desencadene estas acciones. Desde 2021, Chrome aplica por defecto las restricciones Lax SameSite, dado que este es el estándar, se espera que otros navegadores también lo adopten

• Validación basada en Referer - Algunas aplicaciones hacen uso de la cabecera HTTP Referer para intentar defenderse de ataques CSRF, normalmente verificando que la petición se originó en el propio dominio de la web. Esto suele ser menos efectivo que la validación de tokens CSRF

Si nos fijamos en la petición de cambiar email, vemos que cumple estas tres condiciones para ser vulnerable pero que también se está transmitiendo un token CSRF

Los tokens CSRF no tienen por qué enviarse como parámetros ocultos en una solicitud POST, por ejemplo, algunas aplicaciones usan tokens CSRF en los encabezados HTTP. La forma en que se transmiten los tokens tiene un impacto significativo en la seguridad de un mecanismo en su conjunto. En algunos casos, las aplicaciones validan correctamente el token cuando la solicitud utiliza el método POST, pero omiten la validación cuando se utiliza el método GET. Si hacemos click derecho > Change request method, podemos cambiar el método por el que se envía la petición

Al enviar la petición, vemos que nos la toma como válida

Si nos dirigimos a nuestro perfil, vemos que nos ha cambiado el email correctamente

Una vez hemos comprobado que acepta el método GET, tenemos que ver si podemos saltarnos la validación del token CSRF si enviamos la petición usando este método

Mandamos la petición y es aceptada, por lo tanto, podemos confirmar que no se está validando el token CSRF si la petición la mandamos por el método GET

Confirmamos que ha sido tramitada exitosamente accediendo a nuestro perfil

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

Si contamos Burpsuite Professional podemos capturar una petición y pulsar click derecho > Engagement tools > Generate CSRF PoC para que nos genere un payload

Se nos genera este payload, aunque es funcional, en la mayoría de ocasiones vamos a tener que retocarlo un poco para mejorar su desempeño

En mi caso prefiero construir el payload de forma manual, como la solicitud va por GET, no tenemos que añadir el atributo method=GET porque es el método de envío por defecto. Una vez creado, debemos pegar el paylod en el Exploit server

<html>
    <body>
        <form action="https://0aef003a04fed832802f26d100f900ee.web-security-academy.net/my-account/change-email">
            <input type="hidden" name="email" value="pwned@gmail.com">
        </form>
        <script>
            document.forms[0].submit();
          </script>
    </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