¡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 DOM-Based vulnerabilities. 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!

Las vulnerabilidades DOM-based son bastante comunes de ver en entornos productivos, especialmente si hacen mucha manipulación de datos con Javascript. No es raro que, al final, los desarrolladores terminen incluyendo vulnerabilidades por error o desconocimiento. No es la vulnerabilidad más destructiva ni excitante para explotar, incluso a veces es difícil testearla, pero debemos tenerla siempre en cuenta.

Lab1 (Practicioner) – DOM XSS using web messages

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 this lab, use the exploit server to post a message to the target site that causes the print() function to be called.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM-Based XSS usando Web Messages.

Comenzamos mapeando la aplicación y simplemente navegando en la raíz, vemos que la aplicación tiene una escucha de Web Messages activa:

Dado que el mensaje se incluye directamente dentro de un «sink» denominado «innerHTML» sin sanitizar, es posible generar un payload que, una vez enviado como Web Message, ejecute un código Javascript arbitrario. El siguiente mensaje puede ser válido:

<img src=x onerror=print()>

Así las cosas, para resolver este laboratorio podemos utilizar un iframe a través del cual enviaremos dicho mensaje a la web cargada. Para ello, podemos usar el siguiente código:

<iframe src="https://0aa400e30484c94280cd17e600d80069.web-security-academy.net/" onload="this.contentWindow.postMessage('<img src=x onerror=print()>','*')">

Lo relevante del iframe anterior es que envía un mensaje con el contenido resaltado en negrita. Asimismo, dado que indicamos «*» como parámetro «targetOrigin», lo estaremos enviando a todas las ventanas que tengan un listener de Web Messages a la escucha (entre ellas, la ventana cargada en el iframe). Almacenamos el exploit en el «Exploit Server» y se lo lanzamos a la víctima, resolviendo el laboratorio:

Lab2 (Practicioner) – DOM XSS using web messages and a JavaScript URL

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 this lab, construct an HTML page on the exploit server that exploits this vulnerability and calls the print() function.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM-Based XSS usando Web Messages.

Comenzamos mapeando la aplicación y simplemente navegando en la raíz, vemos que la aplicación tiene una escucha de Web Messages activa:

Como vemos, el bloque anterior simplemente comprueba que el string «http:» o «https:» esté en el mensaje que le llega antes de pasarlo al sink «location.href». Por ello, el siguiente mensaje pasaría la validación:

javascript:print()//http:

En base a lo anterior, generamos un iframe de nuevo, en el que incluiremos el payload anterior como parte de un mensaje enviado al cargarse, lanzando por tanto el XSS:

<iframe src="https://0a03009f031097c481696166004800fc.web-security-academy.net/" onload="this.contentWindow.postMessage('javascript:print()//http:','*')">

Almacenamos, enviamos a la víctima y resolvemos el laboratorio:

Lab3 (Practicioner) – DOM XSS using web messages and JSON.parse

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, construct an HTML page on the exploit server that exploits this vulnerability and calls the print() function.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM-Based XSS usando Web Messages.

Comenzamos mapeando la aplicación y simplemente navegando en la raíz, vemos que la aplicación tiene una escucha de Web Messages activa:

Analizamos el código fuente con el objetivo de determinar el payload necesario para llegar al «sink» deseado:

window.addEventListener('message', function(e) {
     var iframe = document.createElement('iframe'), ACMEplayer = {element: iframe}, d;
     document.body.appendChild(iframe);
     try {
         d = JSON.parse(e.data);
     } catch(e) {
         return;
     }
     switch(d.type) {
         case "page-load":
             ACMEplayer.element.scrollIntoView();
             break;
         case "load-channel":
             ACMEplayer.element.src = d.url;
             break;
         case "player-height-changed":
             ACMEplayer.element.style.width = d.width + "px";
             ACMEplayer.element.style.height = d.height + "px";
             break;
     }
}
, false);

Podemos ver que, si enviamos dentro del payload un JSON con la clave «load-channel» controlamos el elemento «src» del iframe. Por tanto, vamos a enviar el siguiente payload:

{"load-channel":"javascript:print()"}

Incluimos dicho payload en el iframe, tal como se hizo en los anteriores laboratorios. Ten en cuenta que hemos escapado las comillas, ya que dan un poco de guerra.

<iframe src='https://0a35001804b0a8808006039e00df0066.web-security-academy.net/' onload='this.contentWindow.postMessage("{\"type\":\"load-channel\", \"url\":\"javascript:print()\"}","*")'>

Almacenamos y enviamos a la víctima para resolver el laboratorio:

Lab4 (Practicioner) – DOM-based open redirection

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 this lab, exploit this vulnerability and redirect the victim to the exploit server.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM-Based open-redirection.

La aplicación no tiene mucha superficie de exposición. Mapeando su contenido simplemente vemos que podemos navegar a los posts y volver a inicio, además de dejar comentarios. Sin embargo, en el botón de volver a inicio es donde se incluye el script vulnerable:

Tal como vemos, el botón se construye a partir de la URL original a la que estamos accediendo. Lo que busca la expresión regular es si hay algún parámetro «url» para extraerlo y hacer la redirección en base a él. Por tanto, si accedemos a una URL como:

https://0a83008904b619db80b6176c00db00b5.web-security-academy.net/post?postId=4&url=https://www.google.es

El script extrae la parte en negrita y redirige al usuario allí. Podemos probar la URL anterior y comprobamos la redirección a Google si damos al botón «Back to blog». Por tanto, podemos utilizar la siguiente URL, acceder y clickar en el botón «Back to blog» para resolver el laboratorio.

https://0a83008904b619db80b6176c00db00b5.web-security-academy.net/post?postId=4&url=https://exploit-0a7d0090048d191a80d6166e014c009d.exploit-server.net/exploit

Lab5 (Practicioner) – DOM-based cookie manipulation

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 this lab, inject a cookie that will cause XSS on a different page and call the print() function. You will need to use the exploit server to direct the victim to the correct pages.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM-Based cookie manipulation, combinada con un XSS.

Para este laboratorio, es fundamental navegar por el mismo. Si accedemos a cualquier producto y volvemos a la lista, podemos observar que, tras ello, aparece un botón denominado «Last viewed product»:

Este menú contextual es dinámico y, como podemos ver en el análisis de peticiones y respuestas, se construye en base a una cookie tal como se puede ver:

Además de lo anterior, el valor de la cookie se ve incluido en una etiqueta dentro del HTML:

La cadena de ataque, por tanto, es sencilla:

• Inyectaremos contenido arbitrario en la cookie para que incluya un pequeño fragmento de código Javascript
• Al cargarse ese Javascript a través de la cookie, se ejecutará en el navegador de la víctima cuando cargue el botón de último producto visto

La siguiente URL hace la primera parte del trabajo, ya que nos genera un payload XSS para poder enviar al usuario:

https://0a7b006203ed7a4b82a88d5b002800a9.web-security-academy.net/product?productId=1&foo=foo'><script>print()</script>

Si accedemos a ella, vemos que no ocurre nada, pero en el momento que cambiamos de página dentro de la aplicación, se ejecuta el payload:

Así que, simplemente adaptando el script, podemos inicializar la cookie y posteriormente hacer que el usuario navegue a la raíz del sitio web para que se ejecute el payload de manera automática. Esto podemos hacerlo a través del iframe en el que incrustaremos el payload (negrita):

<iframe src="https://0a7b006203ed7a4b82a88d5b002800a9.web-security-academy.net/product?productId=1&foo=foo'><script>print()</script>" onload="if(!window.x)this.src='https://0a7b006203ed7a4b82a88d5b002800a9.web-security-academy.net';window.x=1;">

Guardamos el exploit, enviamos a la víctima y resolvemos el laboratorio.

Lab6 (Expert) – Exploiting DOM clobbering to enable XSS

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 this lab, construct an HTML injection that clobbers a variable and uses XSS to call the alert() function.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM Clobbering, combinada con un XSS.

Comenzamos mapeando la aplicación y vemos, en primer lugar, que es posible explotar una vulnerabilidad de DOM Clobbering debido a la asignación de una variable global denominada «avatar» de manera insegura:

Tal como explican en el apartado de PortSwigger dedicado a este punto, el DOM Clobbering suele explotarse con elementos de tipo «anchor», es decir, etiquetas «a». Lo que haremos será generar dos etiquetas con el mismo identificador, una de ellas con el atributo «name» con el valor de la variable global, de forma que sobrescribimos el DOM para que el siguiente comentario adquiera por defecto el valor de nuestro payload si no se incluye otro avatar (es decir, cambiamos el valor por defecto de la variable «avatar» del código de arriba).

<a id=defaultAvatar><a id=defaultAvatar name=avatar href="cid:&quot;onerror=alert(1)//">

El payload final aparece en negrita. Como verás, es un payload específico para evitar la sanitización realizada por DOMPurify, una librería empleada para intentar evitar manipulaciones de DOM. Sobre estas técnicas existen muchos post y sobre cómo bypassearlo (https://portswigger.net/research/bypassing-dompurify-again-with-mutation-xss).

Así que, para explotar la vulnerabilidad, incluimos un comentario con el payload anterior. Tras ello, incluiremos un segundo comentario pero, al estar el DOM sobrescrito, se disparará el payload incluido en el primer comentario.

Como vemos, el avatar del segundo comentario no es el avatar por defecto (el de los otros). Esto es porque se ha sobrescrito la variable global y su valor fue manipulado por el atacante. Con ello, el payload se ejecuta y el laboratorio queda resuelto.

Lab7 (Expert) – Clobbering DOM attributes to bypass HTML filters

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 this lab, construct a vector that bypasses the filter and uses DOM clobbering to inject a vector that calls the print() function.». En este laboratorio el objetivo es explotar una vulnerabilidad DOM Clobbering, combinada con un XSS.

De nuevo, al mapear la aplicación vemos que la única funcionalidad interesante es enviar comentarios. Lanzamos un comentario y observamos cómo la librería HTMLJanitor es utilizada para sanitizar la entrada. Esta librería es vulnerable a DOM Clobbering porque utiliza la propiedad «attributes» para recorrer los elementos a revisar.

Si inyectamos un código HTML en el que sobrescribamos el DOM de forma que incluyamos un elemento cuya propiedad «attributes» no tenga longitud, podemos hacer bypass de esta sanitización.

<form id=x tabindex=0 onfocus=print()><input id=attributes>Focus me

El payload anterior incluye sobrescribir la propiedad «attributes» usando un input. Esto hace que su longitud sea 0, por lo que los atributos del formulario no serán saneados. Por tanto, al ganar el foco de la ventana, el payload se ejecutará. Finalmente, dado que tenemos el payload, generamos un comentario con el formulario cuyo valor no se saneará.

Fíjate que ahí está nuestro comentario. Ahora, lo que necesitamos, es que la víctima acceda a la URL y el formulario adquiera el foco. Para ello, utilizamos un iframe y una función en Javascript que permite que el elemento tome el foco:

<iframe src=https://0a67005d0391da4b80fe036100f600b9.web-security-academy.net/post?postId=10 onload="setTimeout(()=>this.src=this.src+'#x',500)">

Lanzamos a la víctima y con eso… ¡¡Laboratorio resuelto!!

~km0xu95