HTTP request smuggling, basic TE.CL vulnerability

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio tiene un servidor front-end y un servidor back-end. El servidor back-end no admite codificación fragmentada (chunked encoding) y el servidor front-end rechaza solicitudes que no utilicen el método GET o POST

Para resolver el laboratorio, debemos enviar una solicitud smuggleada al servidor back-end, de forma que la siguiente solicitud procesada por el servidor back-end parezca que utiliza el método GPOST

Aunque el laboratorio admite HTTP/2, la solución prevista requiere técnicas que solo son posibles en HTTP/1. Es posible cambiar manualmente de protocolo en el Repeater desde la sección Request attributes del Inspector

---

Resolución

Al acceder a la web vemos esto

Capturamos la petición con Burpsuite, la enviamos al Repeater, eliminamos las cabeceras innecesarias, pulsamos sobre Show non-printable chars y en el apartado Request atributes del Inspector cambiamos el protocolo de HTTP/2 a HTTP/1. Una vez tengamos todo esto hecho, vemos a realizar la petición, si todo funciona bien significa que la petición se puede realizar con las cabeceras que estamos usando

Lo siguiente que debemos de hacer es pulsar sobre el engranaje y descheckear la opción Update Content-Length para que no se actualice el Content-Length

Ahora vamos a cambiar el método a POST, para ello hacemos click derecho > Change request method

Ahora vamos a proceder a testear. He añadido la cabecera Transfer-Encoding con el valor chunked, esto quiere decir que vamos a enviar los datos que se proporcionan en el body en este formato. En este caso, nuestro body seria el contenido que hay entre 3f y el 0. También he añadido la cabecera Content-Length porque también es necesaria

Vamos a explicar la petición. El Content-Length debe indicar un tamaño superior al del body que realmente enviamos. Como el body ocupa 19 bytes, utilizamos un Content-Length de 20. Esto hace que el back-end no dé por finalizada la petición tras leer esos 19 bytes, sino que espere un byte adicional, el cual pertenecerá a la siguiente petición HTTP. Este comportamiento es el que permite que la siguiente petición quede parcialmente absorbida por la petición smuggleada y se produzca la desincronización

En este caso smuggled=yes se podría quitar y el número de bytes sería 5 en vez de 19, de forma que usando un Content-Length de 6 también funcionaría. Si hacemos esto tendríamos que cambiar también el 3f por su valor correspondiente

Luego, el valor 3f es 63 en hexadecimal e indica el tamaño del chunk que va a recibir el frontend. En este caso, la cabecera Content-Length: 20 es necesaria para que el servidor la acepte como una petición válida

Y por último, el Content-Length es 4 porque es el número de bytes que ocupa la primera línea. Esto se hace para que el backend lea solo hasta ahí

El siguiente paso es realizar una petición desde Burpsuite

Una vez hecha esta petición nos vamos al navegador y accedemos a cualquier ruta existente. En este caso yo he accedido a la raíz, y como vemos, nos devuelve el contenido de /post?postId=8 en la respuesta

Una vez hemos hecho esto, podemos afirmar que estamos ante un HTTP request smuggling TE.CL. Una vez ya confirmada la vulnerabilidad, vamos a resolver el laboratorio. Para ello, debemos de hacer una petición utilizando el método GPOST. Así que necesitamos ajustar el valor del Content-Length nuevamente

Una vez hayamos hecho esto, tenemos que enviar dos peticiones. Cuando enviemos la primera veremos que todo se ha ejecutado correctamente

Sin embargo, al efectuar la segunda petición, veremos esto. Lo cual significa que hemos completado el laboratorio correctamente, ya que hemos hecho una petición utilizando el método GPOST