Trying to achieve response Queue Poisoning, or receiving forbidden page response

[cocoh-23]

Hey @dhmosfunk. I have been trying several thing with the vulnerability, and I am seeing the following points:

• If well we are being able to see that an internal endpoint was hit, this is happening because we are being able to generate an OOB interaction (an A query for the burp collaborator domain). I believe the ideal scenario would be, as in classical request smuggling, to be able to actually get the response for example of a /admin page (by being able to smuggle a request that is appended to the next request that is done, and actually getting the response for /admin). When i send the following payload for example: GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/index.php%20HTTP/1.1%0d%0aHost:%20localhost%0d%0aContent-Length:%20200%0d%0a%0d%0a HTTP/1.1 with the smuggled request with a Content-Length of 200, and I send a follow up request, I am not receiving a 403 on my clients, despite the fact I see on the backend logs, that a request for /index.php was made, and received a 403 response code. This behaviour indicates that the follow up request is not being concatenated as part of the body of the smuggled request (/index.php). Do you believe this depends on specific configuration?
• The second point is similar and its about being able to smuggle an entire request in order to trigger response queue poisoning. I will try MaxKeepAliveRequest 1 and get back to you

[cocoh-23]

I believe Keep-Alive should be set to on, in the reverse proxy, as this is how we could turn this request splitting into an Http Desync attack. Dont you think?

[dhmosfunk]

Hello @cocoh-23, the OOB interaction is just for the POC and I call it as a secret functionality, this CVE does not offer a OOB interaction and the behaviour depends on each web app e.g. how the web app is developed . I will add later a specific prefix in order to identify this type of vulnerability causing time delay and error response code.
I think if a web app is vulnerable to this type of Http request smuggling in order to exploit it and achieve queue poisoning some cretirea must be met, Therefore to achieve http response queue poisoning we have to reproduce the criteria on following link.

I will try to reproduce them and come back with further updates.

[cocoh-23]

Hi @dhmosfunk! Yes, I understand that the OOB interaction is an example of your choice to show a possible attack vector. But it shows that the current CVE behaviour does not return the response of the smuggled request. For example I modified index.php to echo some random string, and if I issue the following request which triggers a second request to index.php, I dont see the response:

GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/index.php%20HTTP/1.1%0d%0aHost:localhost%0d%0aFoo:%20bar

Thus it would be great if we could find the way or needed config to trigger response queue poisoning, because it would make this vulnerability not blind. In the current behaviour, we need an OOB, some action happening in the application, or access to the application code in order to confirm the exploitation of the vulnerability.

Finally, I leave a PoC to identify the vulnerability via a backend error because of the smuggled request:

GET /categories/1%20HTTP/1.x%0d%0aFoo:%20bar

PS: I tried a few configurations to reuse connections to the backend, but I could not exploit RQP. Let me know if you are able to do this.

Thanks again.