What is it all about?
As we all know, web-based social engineering attacks typically involve tricking a user into clicking on a malicious link or downloading an infected file through a web-based interface, such as a fake login page or a phishing email that appears to be from a legitimate source. Examples of web-based social engineering attacks include phishing, spear phishing, baiting, and pretexting.
On the other side, HTTP request smuggling is an almost new web application vulnerability (announced by James Kettle albinowax) that involves the manipulation of HTTP requests to bypass security controls and perform unauthorized actions. The attack exploits differences in how back-end and proxy servers interpret HTTP requests containing multiple headers with conflicting instructions. Attackers can use this technique to inject malicious requests into a stream of legitimate traffic, leading to various potential consequences such as information disclosure, data tampering, etc.
In this article, I want to discuss my experiences as a red-teamer in this specific technique and how we abused this vulnerability in our Red Team engagement. There are a lot of contents and labs regarding request smuggling in the Portswigger Academy; It is worth taking the time to understand this article thoroughly and beyond.
Possible Scenarios
Redirection in a combination of a phishing page
The first thing that may be interesting for an attacker is the possibility of phishing without traditional methods. Almost all phishing attacks rely on some social engineering that may fail due to a good security awareness training program. But in our scenario, attackers do not need it! The attacker runs a script continuously to add arbitrary content to the following legitimate user's request, which means you can force a redirection to your desirable URL, possibly a well-designed phishing landing page
Redirection for payload delivery
Just like the first scenario, Request smuggling could lead the user to the attacker-owned URL, but the URL is aimed at a malicious file in this case. By crafting a stealthy BoF, a back-doored app, or a good-looking weaponized MS Office file, the attacker can deliver the payload to every user who uses the vulnerable web app. Again, a semi-phishing attack but in a more technical way and with less social engineering required.
Redirect in the combination of Subdomain take-over
Let's assume that you managed to take over a subdomain (that belongs to the target organization) during the engagement, for example, with an unclaimed S3 bucket, IP dangling, or even a DNS takeover. There are lots of possibilities. For a better understanding, you can check the can-i-take-over-XYZ repository by Edwin "EdOverflow" Foudil (Ed Foudil). Aside from being an excellent chance for direct phishing by redirecting a user to the hijacked sub-domain with request smuggling, you can abuse the sub-domain to steal the redirected user's cookies if those cookies are scoped to the parent domain.
A quick (, short and dirty) demo: [Redirection for payload delivery]
As you may have noticed, When the user downloads our payload due to a vulnerability, the URL in the browser remains the same as the main/vulnerable domain. Worth mentioned that 4 out of 5 payload deliveries were ultimately successful, which is more than usual (at least for me!).
Another point here is that Request Smuggling can easily bypass all Email Protection solutions, rendering security awareness training almost useless.
Conclusion
While social engineering remains a popular attack vector for many hackers, the use of HTTP request smuggling presents a viable alternative that can be just as effective. As demonstrated by the scenarios provided in this article, it could directly impact the effectiveness of payload delivery methods. Also, it can reduce the chance of users' suspicions about malicious files or links.