Open cocoh-23 opened 1 year ago
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?
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.
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.
Hey @dhmosfunk. I have been trying several thing with the vulnerability, and I am seeing the following points:
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?