CL.0 request smuggling
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
From the Proxy -> HTTP history, send the
GET / requestto Burp Repeater twice.
In Burp Repeater, add both of these tabs to a new group.
Go to the first request and convert it to a
POSTrequest (right-click and select Change request method).
In the body, add an arbitrary request smuggling prefix. The result should look something like this:
Change the path of the main POST request to point to an arbitrary endpoint that you want to test.
Using the drop-down menu next to the Send button, change the send mode to Send group in sequence (single connection).
Change the Connection header of the first request to keep-alive.
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.
Deduce that you can use requests for static files under
/resources, such as
/resources/images/blog.svg, to cause a CL.0 desync.
In Burp Repeater, change the path of your smuggled prefix to point to /admin.
Send the requests in sequence again and observe that the second request has successfully accessed the admin panel.
Smuggle a request to
GET /admin/delete?username=carlosrequest to solve the lab.
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.