¡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 relativos a Web Cache Poisoning. 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!

Siendo sinceros, este tipo de vulnerabilidades son más raras de ver en entornos reales, al menos en nuestra experiencia. Cierto es que, si los clientes no hacen uso de cachés o CDNs, difícilmente las encontraremos. Por ello, este tipo de vulnerabilidades son aptas únicamente para aquellos despliegues más avanzados que tengan este tipo de mecanismos.

Lab1 (Practicioner) – Web cache poisoning with an unkeyed header

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, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Accedemos a la raíz del sitio web y observamos que, según las cabeceras, se hace uso de una caché en la aplicación.

En estos casos, debemos enviar siempre la petición a la extensión «Param Miner», que nos tratará de descubrir elementos «unkeyed» en la petición que causen un cambio en la respuesta. Es decir, buscamos elementos que para la caché no alteren la decisión de servir el contenido cacheado o no pero que a su vez podamos controlar con ellos parte de la respuesta.

Además de lo anterior, añadimos un parámetro denominado «cachebuster» con el objetivo de no interferir con las respuestas enviadas por la aplicación a los demás usuarios durante las pruebas. Esto siempre es recomendable. Damos botón derecho, lanzamos «Param Miner» y lanzamos «Guess headers» en este caso.

Como vemos, Burp Suite Professional nos genera una issue a través de Param Miner, indicando que existe la posibilidad de hacer web cache poisoning mediante la cabecera X-Forwarded-Host. Esto es porque el valor de dicha cabecera aparece en la respuesta y no afecta a la decisión de la cache. Por tanto, vamos a evaluar un valor arbitrario para dicha cabecera y ver cómo podemos construir el ataque. Utilizamos el valor de nuestro «Exploit Server» en la cabecera X-Forwarded-Host:

Vemos que el valor se refleja. Pero, lo más importante, es que podemos generar con dicha cabecera una carga de un script hacia nuestro servidor atacante. Concretamente, hacia la siguiente URL:

https://exploit-0ad100000406d00f808f2faf011a002c.exploit-server.net/resources/js/tracking.js

Por tanto, lo que haremos es ejecutar el ataque en dos fases:

• Hostearemos el recurso «/resources/js/tracking.js» con un script malicioso en nuestro «Exploit Server»
• Quitaremos el cache buster y lanzaremos el envenenamiento de la caché para todas las peticiones que lleguen a la raíz sin ningún tipo de parámetro

Tras estas dos fases, cuando un usuario legítimo acceda al sitio, cargará hasta que el tiempo en caché expire nuestro script malicioso. Para evitar esta ventana temporal, simplemente lanzaremos la petición de envenenamiento de manera continua hasta lograr nuestro objetivo. En las siguientes figuras tienes el script malicioso almacenado en el servidor atacante y el envío de petición sin el cache buster. Si sigues estos dos pasos, el laboratorio debería resolverse tan pronto como la víctima acceda a la raíz y por ende descargue el contenido del script malicioso por envenenamiento de caché.

Lógicamente, el script malicioso hace lo que nos pide el laboratorio, alertar con document.cookie. En la vida real, este JavaScript sería seguramente más sofisticado.

Lab2 (Practicioner) – Web cache poisoning with an unkeyed cookie

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, poison the cache with a response that executes alert(1) in the visitor’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Accedemos a la raíz del sitio web y observamos que, según las cabeceras, se hace uso de una caché en la aplicación.

En este caso, no hace falta lanzar «Param Miner», ya que vemos que el valor de la cookie «fehost» se refleja en las respuestas. Elaboramos un payload que nos permita ejecutar «alert(1)»:

fehost=prod-cache-01"}%3balert(1)//

Finalmente, lanzamos la petición sin el cache buster y… ¡¡Laboratorio resuelto!! Esto es porque la víctima ha cargado y ejecutado nuestro payload.

Lab3 (Practicioner) – Web cache poisoning with multiple headers

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, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Descubrimos de nuevo el uso de una caché a través de la petición a la raíz de la aplicación web que estamos analizando:

En este caso, lanzamos «Param Miner» y descubrimos la cabecera «X-Forwarded-Scheme» como potencialmente «unkeyed» y actuando sobre las respuestas. Procedemos a enviar una petición para corroborarlo:

Sin embargo, vemos que aunque alteramos la respuesta, no es directamente explotable. En cualquier caso, volvemos a aplicar el mismo método y le pasamos la nueva petición a «Param Miner».

Procedemos a confirmar el hallazgo de la nueva cabecera «unkeyed» denominada X-Forwarded-Host añadiendo en su valor nuestra dirección de «Exploit Server»:

Tal como se puede apreciar, el contenido de la respuesta cacheada apunta ahora a nuestro servidor atacante. Este comportamiento se repetirá en toda la web, por lo que podemos tomar como objetivo, de nuevo, el recurso «/resources/js/tracking.js» (fíjate que se carga al usar la web normalmente). Para resolver el laboratorio, por tanto, simplemente debemos almacenar el contenido malicioso en dicho recurso de nuestro servidor y lanzar la petición con las dos cabeceras descubiertas al recurso original sin cache buster para que quede cacheada apuntando a nuestro servidor malicioso:

Lab4 (Practicioner) – Targeted web cache poisoning using an unknown header

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, you need to poison the cache with a response that executes alert(document.cookie) in the visitor’s browser. However, you also need to make sure that the response is served to the specific subset of users to which the intended victim belongs.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Sabemos que la víctima lee nuestros comentarios. Además, debido a la cabecera «Vary» implementada en la caché, sabemos que la cabecera «User-Agent» se toma como «keyed». Esto quiere decir que se produce un cacheo de las respuestas en base a dicha cabecera.

Lo primero de todo, por tanto, es tratar de descubrir el «User-Agent» que utiliza la víctima. Para ello, posteamos un comentario con el siguiente contenido, de forma que la víctima se conecte a nuestro servidor atacante:

<img src="https://exploit-0ae300c40449d45da5c5a0dd01e100a4.exploit-server.net/exploit">

Accediendo a los logs, podemos obtener el «User-Agent» objetivo de la víctima:

Ahora, simplemente, repetimos los pasos de los laboratorios anteriores, lanzando la petición a la raíz a «Param Miner» e identificando la cabecera «X-Host» como «unkeyed». Si probamos la dirección de nuestro «Exploit Server» como valor, vemos que de nuevo podemos envenenar la caché apuntando al recurso «/resources/js/tracking.js» de nuestro servidor:

Por tanto, nos quedan únicamente dos pasos para resolver el laboratorio:

• Almacenar el contenido de nuestro script malicioso en nuestro «Exploit Server»
• Quitar el cache buster de la petición y ajustar el User-Agent para que el ataque afecte solamente a la víctima y lanzar la petición hasta que quede en caché

Acuérdate de cambiar el User-Agent, eso sí, para afectar al usuario en cuestión, ya que dicha cabecera es ahora un parámetro «keyed». Si lo ajustar, debería resolverse el laboratorio tan pronto como la víctima acceda a la raíz del sitio.

Lab5 (Expert) – Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria

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, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Mapeamos la aplicación y vemos que en la raíz de la web se utiliza una caché. Asimismo, vemos que existe un script con un parámetro «data.host» cuyo contenido es la propia URL del laboratorio:

De igual modo, vemos que el objeto «data.host» se utiliza para construir una URL en el mismo recurso:

Lanzamos la herramienta «Param Miner» y descubrimos que la cabecera X-Forwarded-Host es «unkeyed» y altera la respuesta. Probamos este hecho en Repeater junto a un cache buster:

Como vemos, por tanto, podemos hacer que los usuarios legítimos tengan que acceder a la siguiente URL de nuestro servidor:

https://exploit-0a1a003504cac3c680660cef01e200e0.exploit-server.net/resources/json/geolocate.json

Revisamos el contenido de la respuesta a dicho archivo JSON en nuestras peticiones originales.

Y visualizamos cómo dicho contenido se incluye en la aplicación a través del recurso «/resources/js/geolocate.js» y más concretamente de su función «initGeoLocate»:

Con todo en mente, parece claro que si logramos escribir código HTML en el parámetro «country» de nuestro JSON, podemos ejecutar código Javascript. Por ello, generamos el recurso «/resources/json/geolocate.json» con el siguiente contenido.

{"country":"<img src=x onerror=alert(document.cookie) />"}

Además, indicamos que el contenido es JSON y asimismo implementamos la cabecera ACAO para evitar ser bloqueados por CORS:

Finalmente, lanzamos la petición a la raíz del sitio web sin el cache buster y resolvemos el laboratorio:

Lab6 (Expert) – Combining web cache poisoning 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 this lab, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Este laboratorio es muy parecido al anterior, teniendo que hacer poisoning de un fichero JSON. Sin embargo, hay que encadenar varios pasos más relativos al idioma. Con el objetivo de que este post no quede muy largo, se recomienda acudir a la explicación de PortSwigger que es muy completa.

Lab7 (Practicioner) – Web cache poisoning via an unkeyed query string

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, poison the home page with a response that executes alert(1) in the victim’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Mapeamos en primer lugar la aplicación, detectando el uso de caché en la raíz del sitio.

Si probamos a inyectar un parámetro cualquiera, vemos que se ve reflejado en la respuesta. Asimismo, también observamos que se puede inyectar código XSS en la misma:

El siguiente paso es hacer peticiones alternativas con el payload anterior y sin él, intentando determinar si la caché hace su trabajo. Si se hace una petición para envenenar la caché con el payload anterior y, sucesivamente, una petición a la raíz sin el query string, vemos que la respuesta está envenenada. Sumando a esto que quitamos la cookie usada como cache buster, resolvemos el laboratorio:

Quizá necesites reenviar la petición durante varias veces para resolver el laboratorio.

Lab8 (Practicioner) – Web cache poisoning via an unkeyed query parameter

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, poison the cache with a response that executes alert(1) in the victim’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Mapeamos en primer lugar la aplicación, detectando el uso de caché en la raíz del sitio.

Lanzamos «Param Miner» para descubrir «query strings» y detectamos un parámetro «unkeyed» denominado «utm_content». Procedemos, pues, a evaluar si podemos alterar la respuesta en base a ese parámetro y detectamos un nuevo XSS (ojo, debemos lanzar las peticiones para ver el contenido reflejado hasta obtener un «miss» en la caché, ya que si no vemos el contenido cacheado por otro usuario).

De nuevo, procedemos a eliminar el query string y vemos cómo el contenido de la respuesta es el mismo. Por tanto, se ha quedado en caché. Simplemente, para resolver el laboratorio, seguimos enviando la petición anterior hasta que la víctima entre en la raíz.

Lab9 (Practicioner) – Parameter cloaking

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 parameter cloaking technique to poison the cache with a response that executes alert(1) in the victim’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Mapeamos en primer lugar la aplicación, detectando el uso de caché en la raíz del sitio.

Lanzamos «Param Miner» y vemos que en este caso, de nuevo el parámetro «utm_content» es perfectamente válido para explorar envenenamiento de caché:

Sin embargo, no podemos utilizarlo para incluir nuestro payload, puesto que su uso está escapado adecuadamente. Buscamos una nueva petición que sí esté en caché y afecte al código client-side. Encontramos que el recurso «/js/geolocate.js» usa un parámetro «callback» para ejecutar y denominar una función JavaScript en la respuesta:

La respuesta también se cachea. Si incluimos el siguiente payload, vemos que además podemos ejecutar un código XSS:

alert(1)//

Obviamente, al cambiar el contenido del parámetro «callback», la key de la caché cambia y, por tanto, a priori no podemos envenenarla. Siguiendo la metodología de Parameter Cloaking» intentamos incluir el parámetro «utm_content» que sabemos que es «unkeyed» para generar una petición que sea interpretada de diferente manera por la caché y por el servidor principal. Fíjate en el siguiente recurso y cómo está formado:

/js/geolocate.js?callback=setCountryCookie&utm_content=foovalue;callback=alert(1)//

Lo que interpreta cada servidor es lo siguiente (dejamos en negrita el contenido de la caché key)

• Caché
  • callback=setCountryCookie
  • utm_content=foovalue;callback=alert(1)//
• Servidor
  • callback=setCountryCookie
  • utm_content=foovalue
  • callback=alert(1)//

Dado que algunos frameworks como Ruby on Rails se quedan con la última aparición del parámetro, la respuesta incluye el payload y la caché key cachea el XSS para el callback a «setCountryCookie», tal como se puede ver:

Así que, simplemente bombardeando la caché hasta que el usuario vaya a la raíz, resolvemos el laboratorio.

Lab10 (Practicioner) – Web cache poisoning via a fat GET request

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, poison the cache with a response that executes alert(1) in the victim’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Comenzamos viendo que la raíz del sitio web cachea el contenido:

Del mismo modo, observamos el uso de caché en la petición a «/js/geolocate.js». En este caso, probaremos a enviar un fat GET con el objetivo de determinar si duplicamos el valor del parámetro «callback» en la URL y en el body del fat GET, cuál coge la aplicación y si se cachean los datos. Fíjate en las siguientes dos capturas cómo conseguimos inyectar el payload en el body del fat GET, mientras que el valor cacheado se ciñe solo a la URL:

Por tanto, la caché solo hace keying del contenido de la URL y no del body de la petición. Sin embargo, el servidor utiliza ambos parámetros y se queda con el del body. Esta discrepancia hace que si mandamos numerosas peticiones fat GET de continuo, el contenido cacheado se almacene y sea ejecutado por la víctima. Para resolver el laboratorio simplemente sigue enviando el fat GET todas las veces necesarias.

Lab11 (Practicioner) – URL normalization

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, take advantage of the cache’s normalization process to exploit this vulnerability. Find the XSS vulnerability and inject a payload that will execute alert(1) in the victim’s browser. Then, deliver the malicious URL to the victim.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

Mapeamos la aplicación y vemos que, ante un mensaje de error en la ruta indicada, el valor se refleja en la respuesta:

Podemos construir un vector de XSS utilizando la siguiente URL:

https://0ad100ed03095c4e80c83f6c002100a8.web-security-academy.net/randomvalue<script>alert(1)</script>

En este caso, la caché key que tendría la caché está en negrita. Como vemos, esta petición se queda en caché, por lo que a priori si enviamos la ruta a la víctima esta ejecutaría el código:

Generamos la URL y se la enviamos al usuario a través del recurso habilitado para ello en el laboratorio y, como vemos, el laboratorio se resuelve. El usuario, eso sí, accederá a la siguiente URL:

https://0ad100ed03095c4e80c83f6c002100a8.web-security-academy.net/randomvalue%3cscript%3ealert(1)%3c%2fscript%3e

Pero la caché key es la misma porque el servidor caché está normalizando las rutas, así que al convertirla la caché key es idéntica a la original.

Lab12 (Expert) – Cache key injection

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, combine the vulnerabilities to execute alert(1) in the victim’s browser. Note that you will need to make use of the Pragma: x-get-cache-key header in order to solve this lab.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

De nuevo, este laboratorio requiere múltiples pasos de explotación y, para no hacer tan largo este post, te recomendamos que acudas a los laboratorios de PortSwigger donde la solución viene sobradamente explicada.

Lab13 (Expert) – Internal cache poisoning

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, poison the internal cache so that the home page executes alert(document.cookie) in the victim’s browser.». En este laboratorio el objetivo es explotar una vulnerabilidad Web Cache Poisoning con el objetivo de ejecutar código en el contexto del navegador de la víctima.

De nuevo, este laboratorio requiere múltiples pasos de explotación y, para no hacer tan largo este post, te recomendamos que acudas a los laboratorios de PortSwigger donde la solución viene sobradamente explicada.

~km0xu95