Researcher Demonstrates 4 New Variants of HTTP Request Smuggling Attack

A new research has identified four new variants of HTTP
request smuggling attacks that work against various commercial
off-the-shelf web servers and HTTP proxy servers.

Amit Klein, VP of Security Research at SafeBreach who presented
the findings today at the Black
Hat^[1] security conference,
said that the attacks highlight how web servers and HTTP proxy
servers are still susceptible to HTTP request smuggling even after
15 years since they were first documented.

What is HTTP Request Smuggling?

HTTP request
smuggling (or HTTP Desyncing) is a technique employed to
interfere with the way a website processes sequences of HTTP
requests that are received from one or more users.

Vulnerabilities related to HTTP request smuggling typically
arise when the front-end (a load balancer or proxy) and the
back-end servers interpret the boundary of an HTTP request
differently, thereby allowing a bad actor to send (or “smuggle”) an
ambiguous request that gets prepended to the next legitimate user
request.

This desynchronization of requests can be exploited to hijack
credentials, inject responses to users, and even steal data from a
victim’s request and exfiltrate the information to an
attacker-controlled server.

The technique was first
demonstrated^[3] in 2005 by a group of
researchers from Watchfire, including Klein, Chaim Linhart, Ronen
Heled, and Steve Orrin. But in the last five years, a number of
improvements^[4] have been devised,
significantly expanding on the attack
surface^[5] to splice requests into
others and “gain maximum privilege access to internal APIs,” poison
web caches, and compromise login pages of popular applications.

What’s New?

The new variants disclosed by Klein involve using various
proxy-server combinations, including Aprelium’s Abyss, Microsoft
IIS, Apache, and Tomcat in the web-server mode, and Nginx, Squid,
HAProxy, Caddy, and Traefik in the HTTP proxy mode.

The list of all new four new variants is as below, including an
old one that the researcher successfully exploited in his
experiments.

• Variant 1: “Header SP/CR junk: …”
• Variant 2 – “Wait for It”
• Variant 3 – HTTP/1.2 to bypass mod_security-like defense
• Variant 4 – a plain solution
• Variant 5 – “CR header” 

When handling HTTP requests containing two Content-Length^[6]
header fields, Abyss, for example, was found to accept the second
header as valid, whereas Squid used the first Content-Length
header, thus leading the two servers to interpret the requests
differently and achieve request smuggling.

In situations where Abyss gets an HTTP request with a body whose
length is less than the specified Content-Length value, it waits
for 30 seconds to fulfill the request, but not before ignoring the
remaining body of the request. Klein found that this also results
in discrepancies between Squid and Abyss, with the latter
interpreting portions of the outbound HTTP request as a second
request.

A third variant of the attack uses HTTP/1.2 to circumvent WAF
defenses as defined in OWASP ModSecurity Core Rule Set (CRS) for preventing HTTP
request smuggling attacks craft a malicious payload that triggers
the behavior.
^[7]

Lastly, Klein discovered that using the “Content-Type: text/plain”
header field was sufficient to bypass paranoia level checks 1 and 2 specified
in CRS and yield an HTTP Request Smuggling vulnerability.

What Are the Possible Defenses?

After the findings were disclosed to Aprelium, Squid, and OWASP
CRS, the issues were fixed in Abyss X1 v2.14, Squid versions 4.12, and
5.0.3 and CRS v3.3.0.

Calling for normalization of outbound HTTP Requests from proxy
servers, Klein stressed the need for an open source, robust web
application firewall solution that’s capable of handling HTTP
Request Smuggling attacks.

“ModSecurity (combined with CRS) is indeed an open source
project, but as for robustness and genericity, mod_security has
several drawbacks,” Klein noted. “It doesn’t provide full
protection against HTTP Request Smuggling [and] it is only
available for Apache, IIS and nginx.”

To this end, Klein has published a C++-based library that
ensures that all incoming HTTP requests are entirely valid,
compliant, and unambiguous by enforcing strict adherence to HTTP
header format and request line format. It can be accessed from
GitHub
here^[12].

^{[2][8][9][10][11]}