CSRF Lab 8

Skills

• SameSite Strict bypass via client-side redirect

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio tiene una función de cambio de correo electrónico vulnerable a CSRF. Para resolver el laboratorio, debemos realizar un ataque CSRF que cambie la dirección de correo electrónico del víctima. Debemos utilizar el servidor de explotación proporcionado para alojar nuestro ataque. Podemos iniciar sesión en nuestra 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

Podemos hacer comentarios en los posts

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 dirigimos a la extensión Logger ++ de Burpsuite vemos que al loguearnos se nos setea una cookie con el atributo SameSite=Strict

Si nos abrimos las herramientas de desarrollador vemos que la cookie no tiene ese atributo, por lo tanto si estamos usando Chrome, se aplicarán las restricciones Lax SameSite por defecto

La diferencia entre un sitio web y un origen es su alcance, un sitio web abarca varios nombres de dominio, mientras que un origen solo incluye uno. Aunque están estrechamente relacionados, es importante no utilizar los términos indistintamente, ya que mezclarlos puede tener graves consecuencias para la seguridad. Se considera que dos URL tienen el mismo origen si comparten exactamente el mismo esquema, nombre de dominio y puerto

Como podemos ver en este ejemplo, el término sitio web es mucho menos específico, ya que solo tiene en cuenta el esquema y la última parte del nombre de dominio. Fundamentalmente, esto significa que una petición de origen cruzado (cross-origin) puede seguir siendo del mismo sitio web, pero no al revés. Esta es una distinción importante, ya que significa que cualquier vulnerabilidad que permita la ejecución de código JavaScript puede ser utilizada para eludir las defensas del sitio web en otros dominios que pertenecen al mismo sitio web

Antes de que se introdujera el mecanismo SameSite, los navegadores enviaban cookies en cada solicitud al dominio que las emitía, incluso si la solicitud era originada por un sitio web de un tercero que no estáno relacionado con el sitio web. SameSite funciona permitiendo que los navegadores y los propietarios de sitios web limiten qué solicitudes entre sitios, si es que hay alguna, deben incluir ciertas cookies. Esto puede ayudar a reducir la exposición de los usuarios a los ataques CSRF, que inducen al navegador de la víctima a emitir una solicitud que desencadena una acción perjudicial en el sitio web vulnerable. Dado que estas solicitudes generalmente requieren una cookie asociada con la sesión autenticada de la víctima, el ataque fallará si el navegador no la incluye. Todos los navegadores más importantes actualmente soportan los siguientes niveles de restricción de SameSite

• Strict - Si una cookie se establece con el atributo SameSite=Strict, los navegadores no la enviarán en ninguna solicitud entre sitios web. Esto significa que si el sitio objetivo de la solicitud no coincide con el sitio web que se muestra actualmente en la URL del navegador no se incluirá la cookie. Esto se recomienda cuando se configuran cookies que permiten al usuario modificar datos o realizar acciones sensibles, como acceder a páginas que solo están disponibles para usuarios autenticados

• Lax - Las restricciones SameSite=Lax significan que los navegadores enviarán la cookie en solicitudes entre sitios web, pero solo si la solicitud utiliza el método GET y si la solicitud es el resultado de una navegación de nivel superior, es decir, que requiere interacción por parte del usuario, como hacer click en un enlace. Esto significa que la cookie no se incluirá en solicitudes POST entre sitios web, por ejemplo. Dado que las solicitudes POST generalmente se utilizan para realizar acciones que modifican datos o el estado (al menos según las mejores prácticas), son mucho más propensas a ser el objetivo de ataques CSRF. De igual manera, la cookie no se incluirá en solicitudes en segundo plano, como aquellas iniciadas por scripts, iframes o referencias a imágenes y otros recursos

• None - Si una cookie se establece con el atributo SameSite=None, esto desactiva las restricciones SameSite por completo independientemente del navegador. Como resultado, los navegadores enviarán esta cookie en todas las solicitudes al sitio web que la emitió, incluso aquellas que fueron originadas por sitios web de terceros no relacionados con el sitio web principal. Con la excepción de Chrome, este es el comportamiento predeterminado utilizado por los navegadores más famosos si no se proporciona un atributo SameSite al configurar la cookie. Existen razones legítimas para deshabilitar SameSite, como cuando la cookie está destinada a ser utilizada desde un contexto de terceros y no otorga al usuario acceso a datos o funcionalidades sensibles, un ejemplo, serían las tracking cookies. Si nos encontramos con una cookie configurada con SameSite=None o sin restricciones explícitas, vale la pena investigar si tiene algún propósito. Cuando el comportamiento Lax fue adoptado por Chrome rompió algunas funcionalidades en las webs. Como solución rápida, algunos sitios web optaron por desactivar las restricciones SameSite en todas las cookies, incluidas las potencialmente sensibles. Al configurar una cookie con SameSite=None, el sitio web también debe incluir el atributo Secure, lo que garantiza que la cookie solo se enviará en mensajes encriptados a través de HTTPS. De lo contrario, los navegadores rechazarán la cookie y `no se seteará

Si una cookie se establece con el atributo SameSite=Strict, los navegadores no la incluirán en ninguna solicitud de un sitio web diferente al que la estableció. Sin embargo, es posible eludir esta limitación si conseguimos encontrar un gadget que genere una solicitud secundaria dentro del mismo sitio web

Un posible gadget es una redirección en el lado del cliente que construye dinámicamente el objetivo de la redirección utilizando una entrada controlada por el atacante, como los parámetros de la URL. Para más ejemplos, podemos consultar los materiales de Portswigger sobre DOM-based open redirection https://portswigger.net/web-security/dom-based/open-redirection

En cuanto a los navegadores, estas redirecciones en el lado del cliente no se consideran realmente redirecciones. La solicitud resultante se trata como una solicitud ordinaria e independiente. Lo más importante es que se trata de una solicitud dentro del mismo sitio web, así que incluirá todas las cookies relacionadas con el sitio web, sin importar las restricciones que estén en su lugar

Si conseguimos manipular este gadget para generar una solicitud secundaria maliciosa, esto nos permitirá eludir completamente las restricciones de las cookies SameSite. El gadget en este laboratorio lo podemos encontrar si miramos la peticiones que se hacen cuando comentamos en un post

Aquí podemos ver el archivo .js al que se está llamando

Vemos que no hay ningún tipo de sanitización por lo que podemos hacer un Path Traversal. Lo podemos comprobar accediendo https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8, pasados tres segundos nos redirigirá a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/8, pero si accedemos a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../ nos redirige a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../. Una vez comprobado esto, el siguiente inspeccionar la forma en la que se envía el formulario para cambiar el correo electrónico

Comprobamos que podemos cambiar el correo electrónico a través del método GET, para ello capturamos la petición con Burpsuite y hacemos click derecho > Change request method

Podemos generar un CSRF PoC haciendo click derecho > Engagements tools > Generate CSRF PoC pero en este caso no va a ser funcional porque no podemos enviar ningún formulario debido a que el atributo de la cookie SameSite es Strict

En mi caso prefiero crear los payload manualmente así que nos dirigimos al Exploit server y nos crafteamos un payload

<html>
    <body>
        <script> 
            document.location = 'https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../../my-account/change-email?email=testing%40gmail.com%26submit=1';
        </script>
    </body>
</html>

Si pulsamos en View exploit vemos como nos cambia el email, para completar el laboratorio debemos pegar el payload 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