Lab: Server-side pause-based request smuggling
What Is Server-Side Pause-Based Desync
Server-side pause-based desync is a technique where an attacker intentionally pauses while sending an HTTP request to confuse the front-end and back-end servers.
The attacker sends part of a request and then waits. During this pause, the two servers may handle the connection differently. For example, one server may think the request is still being sent, while the other may decide that the connection has timed out or that the request is finished.
When the attacker continues sending data, the servers can become out of sync, causing the remaining data to be interpreted unexpectedly.
In simple words:
The attacker uses a carefully timed pause to make two servers disagree about what is happening with the request.
Unlike traditional request smuggling, which often relies on conflicting headers, pause-based desync mainly takes advantage of differences in how servers handle slow requests and timeouts.
Conditions For Server-Side Pause Based Desync
- The front-end server must immediately forward each byte of the request to the back-end rather than waiting until it has received the full request.
— WHY ? Because the attacker needs the back-end to receive the partial request before the attacker pauses. - The front-end server must not (or can be encouraged not to) time out requests before the back-end server.
— WHY ? If the front-end gives up first, it may close the connection before the attack can continue. This difference in timeout behavior is what helps create the desynchronization. - The back-end server must leave the connection open for reuse following a read timeout.
— WHY ? If the back-end simply closed the connection completely after the timeout, the attacker wouldn’t have an existing connection to reuse, and this particular desync wouldn’t work.
Solution To Lab
1. Just Inspecting:
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.
2. Getting a Redirect:
When you issue request for GET /resources. Observe that you are redirected to /resources/.
Get Amna Lodhi’s stories in your inbox
Join Medium for free to get updates from this writer.
The /resources directory isn't special because of its name. We use it because requesting a valid directory without its trailing slash causes Apache to generate a redirect. That redirect can occur before the request body is fully consumed, leaving data on a reusable connection and creating the opportunity for a CL.0 desynchronization.
3. Crafting The Attack:
Send the crafted request to turbo intruder, and paste the given script in python editor panel.
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
requestsPerConnection=500,
pipeline=False)# First request — the smuggled request with delay
engine.queue(target.req, pauseMarker=[‘\r\n\r\n’], pauseTime=61000)
# Second request — the normal request that will be poisoned
engine.queue(target.req)def handleResponse(req, interesting):
table.add(req)
pauseMarker=[‘\r\n\r\n’] tells the server where to pause. Here double CRLF indicate the end oh headers before starting of the body. Later in this lab we will update the pauseMarker for the server to pause for the smuggled requests body.
3.1 Accessing Admin Panel:
If we normally try access admin panel it gives 403 forbidden but a totally different response in a server-side pause desync.
A 401 Unauthorized error means a web server rejected your request because you did not provide valid login credentials.
The second entry in the turbo table above 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.
4. Performing The Exploit
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. In the lab, 61 seconds is chosen because the vulnerable back-end has a 60-second read timeout and this timeout is necessary for the smuggled request to trick the server into granting access to restricted page.
Make a note of your “csrf token” and “session cookie” from the response of above request to place in the new request as below.
Update pause-marker: pauseMarker=[‘Content-Length: 53\r\n\r\n’] in the python script.
Launch the attack and lab will be solved.
References & Learning
This write-up is based on my hands-on practice and learning from the PortSwigger Web Security Academy. I’ve used their labs and documentation as references to understand server-side pause-based desynchronization, and this article summarizes my own understanding of the concepts and techniques involved.
