CL.0 request smuggling

Description

This lab is vulnerable to CL.0 request smuggling attacks. The back-end server ignores the Content-Length header on requests to some endpoints.

Reproduction and proof of concept

Probe for vulnerable endpoints

  1. From the Proxy -> HTTP history, send the GET / request to Burp Repeater twice.

  2. In Burp Repeater, add both of these tabs to a new group.

  3. Go to the first request and convert it to a POST request (right-click and select Change request method).

  4. In the body, add an arbitrary request smuggling prefix. The result should look something like this:

HTTP header smuggling

  1. Change the path of the main POST request to point to an arbitrary endpoint that you want to test.

  2. Using the drop-down menu next to the Send button, change the send mode to Send group in sequence (single connection).

  3. Change the Connection header of the first request to keep-alive.

  4. Send the sequence and check the responses.

  • If the server responds to the second request as normal, this endpoint is not vulnerable.

  • If the response to the second request matches what you expected from the smuggled prefix (in this case, a 404 response), this indicates that the back-end server is ignoring the Content-Length of requests.

  1. Deduce that you can use requests for static files under /resources, such as /resources/images/blog.svg, to cause a CL.0 desync.

HTTP header smuggling

Exploit

  1. In Burp Repeater, change the path of your smuggled prefix to point to /admin.

  2. Send the requests in sequence again and observe that the second request has successfully accessed the admin panel.

  3. Smuggle a request to GET /admin/delete?username=carlos request to solve the lab.

HTTP header smuggling

Exploitability

An attacker will need to identify a vulnerable endpoint, smuggle a request to the back-end to access to the admin panel at /admin, then delete the user carlos.