Finding My First Bug: HTTP Request Smuggling

How did I Find the Bug?

During my recon when I found all the possible subdomains I just started visiting them one by one, the vulnerable subdomain gave a 403 Forbidden error along with the version of the webserver.

Then I checked the Burpsuite’s passive scanner which picked up the version number and reported that this version might be vulnerable.

What was causing the bug?

The website was using an old version on Web-Server which extends Nginx, this older version of web-server caused the website to allow this desync attack.

What is HTTP Request Smuggling?

As I understand HRS is this vulnerability where an attacker can send an ambiguous request which can desynchronize the servers, leaving the socket to the backend poisoned with a harmful response. This response will then be served up to the next visitor.

How did I perform the attack?

On this domain the desync occurs when we send a request with a Content-Length header and Transfer-Encoding header, the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header, which allows us to perform an HTTP request smuggling attack.

POST /i HTTP/1.1 Host: ... Connection: keep-alive ... Content-Length: 55 Transfer-Encoding: chunked 0 GET /publicDocs/ HTTP/1.1 Host: ... foo: x

What was the Impact?

Since this technique allows attackers to bypass rules in frontend systems, it may also be possible to access internal content that’s meant to be private.

So I found a login page which was meant for the staff only and a few other Documents which normally gave 403 errror but through this technique we got a 200 status code.

Final thoughts

This was my first report on a bug-bounty platform and finding a valid bug and getting a bounty was a great experience. I learned a lot about how to write a good report, I learned a lot from disclosed report and portswigger’s website.