Response queue poisoning via H2.TE request smuggling

This lab is vulnerable to request smuggling due to the front-end server downgrading HTTP/2 requests even when they contain an ambiguous length. By exploiting this flaw using an H2.TE technique, we can perform response queue poisoning and interfere with subsequent requests. In this writeup, we leverage this behavior to gain unauthorized access to the /admin panel, which is accessed by an admin user approximately every 15 seconds.

Step 1: Intercept

Grab the request for the root endpoint and send it to Repeater.

Step 2: Craft the attack

Change the request method to POST.

Rename the request to “attack request.” In Repeater options, toggle off “Update Content-Length.” Remove all unnecessary headers, keeping only Host and Content-Type. Turn on “Show non-printable characters.”

Add the Transfer-Encoding header and set it to chunked. Then poison the backend with a non-existent GET request. Add the header X-Ignore and set it to x.

Send the request for the root endpoint to Repeater again, but don’t change anything. Label the request “normal request.”

Send the attack request, then send the normal request. Repeat this process until the normal request returns a 404 response, which confirms the vulnerability.

Step 3: Exploitation

Modify the URI path of the original POST request to something that does not exist. Then, in the second request (GET), make it a complete request by adding the host from the original request to poison the backend response queue.

After that, keep sending the request until you receive any response other than 404 — commonly a 302 response.

To make this easier, use Intruder.

Set the attack type to Sniper. In the Payloads tab, choose Null payloads, then configure it to continue indefinitely.

In the Settings tab, turn off Update Content-Length in the request header. This prevents Burp Intruder from adding a Content-Length header, which would break the request smuggling attack.

In the Resource Pool, create a new pool with a maximum of 1 concurrent request and a delay of 800 milliseconds between requests.

Start the attack and filter the status codes to show only 300-level responses for easier navigation.

Once you receive a 302 status code, check the response and copy the administrator’s session key.

Go back to the website, paste the copied session key into the cookie editor extension, save it, and then refresh the page.

You can now access the admin panel and delete any users you choose.

To prevent this attack, ensure that your web application properly validates and separates incoming requests. Avoid trusting headers from clients, and make sure the server handles each request independently. Implement proper access controls so sensitive actions, like deleting users, require verification. Regularly update your server and web frameworks to patch known vulnerabilities.