HTTP Request Smuggling: How to Detect and Attack?

What is HTTP Request Smuggling Attack?

HTTP request smuggling is an attack that aims to exploit the desynchronization between front-end proxies and back-end servers. This vulnerability allows attackers to infer the processing of the HTTP requests by injecting an ambiguous request that can subvert the application logic.

In simpler terms, the HTTP request can be sent as a single request to front-end proxies but interpreted as split requests by the backend server. So where does part of the request goes to? It will be prepended to the next request and ultimately interfere with the way the application processes the request, allowing an attacker to bypass security controls, and gain unauthorized access to sensitive data, and account takeover.

The following picture presents the best graphical illustration of HTTP Request Smuggling (credits to portswigger.net)

How to Detect HTTP Request Smuggling Vulnerability?

The HTTP request smuggling attack is relatively harder to grasp as it involves a complex network environment with different RFC standards implementation. It is not as intuitive as compared to other web attack methods.

One can manually craft a payload to induce time delay and differentiate responses to find and confirm the vulnerability. However, this can be daunting for many and they will likely overlook the vulnerability as this requires relatively skilful testers to accomplish. Hence, using proven automated tools will be a safer approach.

In any vulnerability assessment and detection approach, more than one tool should be used in order to ensure nothing slips through the crack. The following two tools are particularly effective (at the time of writing) and should be used together to complement each other.

As we all know, the detection of vulnerability is only just the beginning of an attack. We still need to identify and develop an explicit request aka payload to bypass network control or exfiltrate sensitive data.

1. HTTP Request Smuggling in Burp Scanner

The Burp scanner detects the vulnerability by sending requests that will cause a time delay in the application’s responses. Over the course of our penetration testing engagements, the detection results pickup by the scanner can be false-positive after further manual analysis.

2. Smuggler by defparam

This tool is highly flexible as it provides the option to select predefined configuration profiles or create your own configuration file. Also comes with desync template scripts for Turbo Intruder to send the request multiple times at extreme speed.

What Can We Do with HTTP Smuggling Attack?

There are several dangerous actions we can achieve using this vulnerability. Here, we are going to discuss two of those using two different attack techniques, which are more critical in severity when an attack is successful.

There are 3 main attack types and which attack type to use depends on the behaviour of the two servers:

• CL.TE: the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.
• TE.CL: the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.
• TE.TE: the front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.

The following synonyms will be used to describe:

CL — Content-Length

TE — Transfer-Encoding

Before we dive into how to exploit account takeover and bypass security control using an HTTP Smuggling attack, let’s analyse one of the attack types in a simulated environment with the following setup. Once we understand the mechanics of one type, it will form the building block for other attack types.

Proxy server : HaProxy 2.0

Back-end server: Gunicorn 20.0.4

In Figure 2, the HaProxy uses Content-Length and ignores the Transfer-Encoding, in this situation, the entire POST body will be parsed to the back-end. The obfuscated Transfer-Encoding:[\x0b] chunked was parsed to the Gunicorn back-end server.

However, the back-end server Gunicorn interpreted this request as two requests instead of one as shown in the response received in Figure 2. This is because it uses Transfer-Encoding header to process the request. The 0 followed by 2 new lines splits the request into two causing the back-end server to send two responses.

By now, we should be more ready to discuss the aforementioned two exploits:

1. Account Takeover

In this example, a TE.CL vulnerability is used for account takeover (Figure 3).

The objective is to infer the back-end server to append requests of another user and redirect them to the attacker-controlled environment.

In this case, the reverse-proxy will send the entire request to the back-end. But, the back-end is going to process only the 1a (4 bytes) as indicated in the Content-Length. Therefore, the next request starting POST /login HTTP/1.1 will be handled as Transfer-Encoding interpretation.

The Content-Length of the smuggled request indicates the length of the next request that is going to be appended to the x parameter. It is necessary to adjust the length to capture the sensitive values of the next requests. In this attack, the goal is to capture other users’ session keys and then use the stolen key for account takeover.

2. Bypass Front-end Security Control

In this example, a CL-TE vulnerability is used to bypass front-end security control (Figure 4).

When the front-end implemented controls to block access to a restricted endpoint, such as /admin. And the back-end server accepts every request without further checking. In this situation, an HTTP request smuggling vulnerability can be used to bypass the access controls, by smuggling a request to the restricted URL.

In this example, the front-end proxy server only processes the request header of Content-Length, which is 129 byte long; so the entire request will be sent to the back-end. However, the back-end server ignores the Content-Length, only handling the request header of Transfer-Encoding. When back-end reads 0 followed by 2 new lines, it will regard the first request has completed, leaving the remaining request GET /admin HTTP/1.1 in the buffer, waiting for the next request to arrive, when latter request smuggled into next request and being processed, it grants unauthorized access to the restricted URL.

Wrapping Up

HTTP Request Smuggling is a weaponized attack that can smuggle requests beyond the application logic boundaries. The severity of the vulnerability is dependent on the intent of the smuggled requests. There is a variation of by-product exploits that can be achieved through request smuggling. For example, open redirect, reflected XSS, web cache poisoning and etc in addition to the two exploits we have discussed.

Since the HTTP request smuggling abuse the different configurations and protocol interpretation are implemented in front-end and back-end servers. Thus, prevention is relatively tricky in nature, and applying a preventive measure may lead to efficiency issues or other attacks.

There are some measures we can take to protect from these attacks:

• Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
• Configure the front-end server to exclusively use HTTP/2 to communicate with back-end systems. This protocol prevents ambiguity within the boundaries between requests.
• Use the same web server software with the same configuration for the front-end and back-end servers.

In some cases, vulnerabilities can be avoided by making the front-end server normalize ambiguous requests or making the back-end server reject ambiguous requests and close the network connection. However, these defences are potentially more error-prone than the mitigations stated above. If you wish to understand more about how to avoid such vulnerabilities, reach out to us here.

References:

https://portswigger.net/web-security/request-smuggling/exploiting

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

https://blog.csdn.net/qq_37865996/article/details/102529396

Numen Cyber Labs is committed to facilitating the safe development of Web 3.0. We are dedicated to the security of the blockchain ecosystem, as well as operating systems & browser/mobile security. We regularly disseminate analyses on topics such as these, please stay tuned for more!

This blog was originally published on our Medium Account.