Exploiting HTTP request smuggling to reveal front-end request rewriting

Portswigger Lab writeup » Exploiting HTTP request smuggling to reveal front-end request rewriting

Descripción

This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.

There’s an admin panel at /admin, but it’s only accessible to people with the IP address 127.0.0.1. The front-end server adds an HTTP header to incoming requests containing their IP address. It’s similar to the X-Forwarded-For header but has a different name.

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.

Exploiting HTTP request smuggling to reveal front-end request rewriting writeup

Dividiremos el laboratorio en dos fases:

Detectar el tipo de vulnerabilidad

Primero, tendremos que verificar el tipo de vulnerabilidad:

Modificaremos las peticiones a la raíz en el ‘Repeater’ de la siguiente forma:

1. En Inspector -> Request attributes, cambiamos la versión de HTTP a 1.1.
2. Damos Click derecho -> Change request method, para cambiar el método a POST.
3. Añadimos la propiedad ‘Transfer-encoding’ con el valor chunked.
4. Activamos la opción de ver los caracteres especiales con ‘\n’.
5. En opciones, a la derecha de ‘Save’, desactivaremos la opción de ‘Update content length’, al menos hasta que sepamos el tipo de vulnerabilidad.
6. De manera opcional también se pueden borrar todos los atributos no necesarios para este laboratorio, como se puede ver en la siguiente captura:

Comprobamos así que consiste en una vulnerabilidad CL.TE, por lo que volvemos a activar la opción ‘Update content length’.

CL.TE significa lo siguiente:

• El servidor front-end utiliza la propiedad del encabezado HTTP ‘Content-Length’.
• El servidor back-end utiliza la propiedad del encabezado HTTP ‘Transfer-Encoding’.

Preparar la petición para hacer el ataque CL.TE

En este caso nuestra petición de ataque será la siguiente:

• Terminando la primera petición con ‘\r\n0\r\n\r\n’, y llevando la petición GET ‘/admin’ al backend con nuestra petición normal a la ‘/’.

El resultado de enviar la petición maliciosa será el siguiente:

Y el de enviar la petición normal:

Confirmando que el ataque se ha realizado.

Acceder a /admin

Intentaremos añadir a la petición el siguiente código:

X-Forwarded-For: localhost\r\n

Pero no funcionará, lo más probable es que el frontend esté modificando nuestra petición y añadiéndole un encabezado HTTP personalizado. Dado que tenemos una barra de búsqueda en el laboratorio, vamos a intentar que el servidor introduzca en ella toda la información posible del encabezado.

La petición maliciosa será la siguiente:

1. Se ha cambiado el método de la petición en el cuerpo de la petición maliciosa a POST.
2. Se ha añadido la etiqueta ‘Content-Type’ para interactuar con la barra de búsqueda.
3. Se ha modificado el ‘Content-Length’ para que sea idéntico al tamaño de la petición normal (puede ser mayor o menor, pero si es demasiado grande, se corre el riesgo de provocar un timeout).
4. Se ha añadido en el cuerpo de la petición el atributo ‘search=’, para llamar a la barra de búsqueda con la información que añada el servidor:

Al enviar la petición maliciosa y después la correcta, veremos lo siguiente:

Ahora sabemos que el atributo es ‘X-ssZtdW-Ip:’, lo añadimos a nuestra petición anterior con el valor 127.0.0.1. Si simplemente lo añadimos nos devolverá el error de que hay encabezados HTTP duplicados, tendremos que enviar la segunda petición (la correcta) en el cuerpo de la maliciosa, como hemos hecho en el laboratorio anterior (Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability):

Nota: Al poner el ‘Content-Type’ en 3, el servidor procesa el ‘x=’, pero espera un byte más, ahí entra toda la petición no maliciosa.

Enviando la otra petición podremos acceder al panel del administrador:

Cambiamos la URL de la petición maliciosa por ‘/admin/delete?username=carlos’, y como estamos ante un ataque CL.TE, no tenemos que actualizar el ‘Content-Length’, se hace sólo. Al enviar las dos peticiones completaremos el laboratorio: