HTTP Request Smuggling

This blog is based on the HHTP Request Smuggling room from TryHackMe.

What is HTTP Request Smuggling?

HTTP Request Smuggling is a vulnerability that arises when there are mismatches in different web infrastructure components. This includes proxies, load balancers, and servers that interpret the boundaries of HTTP requests.

Request splitting or HTTP desync attacks are possible because of the nature of keep-alive connections and HTTP pipelining, which allow multiple requests to be sent over the same TCP connection. Without these mechanisms, request smuggling wouldn’t be feasible. When calculating the sizes for Content-Length (CL) and Transfer-Encoding (TE), it’s crucial to consider the presence of carriage return \r and newline \n characters. These characters are not only part of the HTTP protocol’s formatting but also impact the calculation of content sizes.

While testing for request smuggling vulnerabilities, it’s important to note that some tools might automatically “fix” the Content-Length header by default. This means if you’re using such tools to run payloads, your Content-Length values might get overwritten, potentially changing the test results.

Importance of Understanding HTTP Smuggling Request

1. Smuggled requests might evade security mechanisms like Web Application Firewalls. This potentially leads to unauthorized access or data leaks.
2. Attackers can poison web caches by smuggling malicious content, causing users to see incorrect or harmful data.
3. Smuggled requests can be chained to exploit other vulnerabilities in the system, amplifying the potential damage.
4. Due to the intricate nature of this vulnerability, it can often go undetected, making it crucial for security professionals to understand and mitigate it.

Components of Modern Web Applications

Modern web applications are no longer straightforward, monolithic structures. They are composed of different components that work with each other. Below are some of the components that a modern web application usually consists of:

1. Front-end server: This is usually the reverse proxy or load balancer that forwards the requests to the back-end.
2. Back-end server: This server-side component processes user requests, interacts with databases, and serves data to the front-end. It’s often developed using languages like PHP, Python, and Javascript and frameworks like Laravel, Django, or Node.js.
3. Databases: Persistent storage systems where application data is stored. Examples of this are databases like MySQL, PostgreSQL, and NoSQL.
4. APIs (Application Programming Interfaces): Interfaces allow the front and back-end to communicate and integrate with other services.
5. Microservices: Instead of a single monolithic back-end, many modern applications use microservices, which are small, independent services that communicate over a network, often using HTTP/REST or gRPC.

Load Balancers and Reverse Proxies

1. Load Balancers: These devices or services distribute incoming network traffic across multiple servers to ensure no single server is overwhelmed with too much traffic. This distribution ensures high availability and reliability by redirecting requests only to online servers that can handle them. Load balancing for web servers is often done by reverse proxies. Examples include AWS Elastic Load Balancing, HAProxy, and F5 BIG-IP.
2. Reverse Proxies: A reverse proxy sits before one or more web servers and forwards client requests to the appropriate web server. While they can also perform load balancing, their primary purpose is to provide a single access point and control for back-end servers. Examples include NGINX, Apache with mod_proxy, and Varnish.

Role of Caching Mechanisms

Caching is a technique used to store and reuse previously fetched data or computed results to speed up subsequent requests and computations. In the context of web infrastructure:

1. Content Caching: By storing web content that doesn’t change frequently (like images, CSS, and JS files), caching mechanisms can reduce the load on web servers and speed up content delivery to users.
2. Database Query Caching: Databases can cache the results of frequent queries, reducing the time and resources needed to fetch the same data repeatedly.
3. Full-page Caching: Entire web pages can be cached, so they don’t need to be regenerated for each user. This is especially useful for websites with high traffic.
4. Edge Caching/CDNs: Content Delivery Networks (CDNs) cache content closer to the users (at the “edge” of the network), reducing latency and speeding up access for users around the world.
5. API Caching: Caching the responses can significantly reduce back-end processing for APIs that serve similar requests repeatedly.

Request Smuggling CL,TE

CL.TE stands for Content-Length/Transfer-Encoding. The name CL.TE comes from the two headers involved: Content-Length and Transfer-Encoding. In CL.TE technique, the attacker exploits discrepancies between how different servers (typically a front-end and a back-end server) prioritize these headers. For example:

• The proxy uses the Content-Length header to determine the end of a request.
• The back-end server uses the Transfer-Encoding header.

Because of this discrepancy, it’s possible to craft ambiguous requests that are interpreted differently by each server. For example, Imagine sending a request with both Content-Length and Transfer-Encoding headers. The front-end server might use the Content-Length header and think the request ends at a certain point due to the provided number of bytes. In contrast, the back-end server, relying on the Transfer-Encoding header, might interpret the request differently, leading to unexpected behaviour.

Exploiting CL.TE for Request Smuggling

To exploit the CL.TE technique, an attacker crafts a request that includes both headers, ensuring that the front-end and back-end servers interpret the request boundaries differently. For example, an attacker sends a request like:

POST /search HTTP/1.1
Host: example.com
Content-Length: 80
Transfer-Encoding: chunked

0

POST /update HTTP/1.1
Host: example.com
Content-Length: 13
Content-Type: application/x-www-form-urlencoded

isadmin=true

Here, the front-end server sees the Content-Length of 80 bytes and believes the request ends after  isadmin=true. However, the back-end server sees the Transfer-Encoding: chunked and interprets the 0 as the end of a chunk, making the second request the start of a new chunk. This can lead to the back-end server treating the POST /update HTTP/1.1 as a separate, new request, potentially giving the attacker unauthorized access.

Incorrect Content-Length

When creating a request smuggling payload, if the Content-Length is not equal to the actual length of the content, several problems might arise. First, the server might process only the portion of the request body that matches the Content-Length. This could result in the smuggled part of the request being ignored or not processed as intended. For example, in the below screenshot, the original size of the body is 24 bytes.

To verify that the Content-Length is valid, we can check the /submissions directory to verify if the whole body was saved in the .txt file.

Since the size of the body username=test&query=test is 24 bytes, sending a Content-Length with a size lower than this will instruct the back-end server to interpret the request body differently. For example, if we set the Content-Length to 10 bytes while retaining the original content of the body, the back-end server will only process a part of that request body.

Request Smuggling TE,CL

TE.CL stands for Transfer-Encoding/Content-Length. This technique is the opposite of the CL.TE method. In the TE.CL approach, the discrepancy in header interpretation is flipped because the front-end server uses the Transfer-Encoding header to determine the end of a request, and the back-end server uses the Content-Length header.

The TE.CL technique arises when the proxy prioritizes the Transfer-Encoding header while the back-end server prioritizes the Content-Length header.

Example: If an attacker sends a request with both headers, the front-end server or proxy might interpret the request based on the Transfer-Encoding header, while the back-end server might rely on the Content-Length header. This difference in interpretation might interpret the request differently, leading to unexpected behaviour.

Exploiting TE.CL for Request Smuggling

To exploit the TE.CL technique, an attacker crafts a specially designed request that includes both the Transfer-Encoding and Content-Length headers, aiming to create ambiguity in how the front-end and back-end servers interpret the request.

For example, an attacker sends a request like:

POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked

4c
POST /update HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

isadmin=true
0

In the above payload, the front-end server sees the Transfer-Encoding: chunked header and processes the request as chunked. The 4c (hexadecimal for 76) indicates that the next 76 bytes are part of the current request’s body. The front-end server considers everything up to the 0 (indicating the end of the chunked message) as part of the body of the first request.

The back-end server, however, uses the Content-Length header, which is set to 4. It processes only the first 4 bytes of the request, not including the entire smuggled request POST /update. The remaining part of the request, starting from POST /update, is then interpreted by the back-end server as a separate, new request.

The smuggled request is processed by the back-end server as if it were a legitimate, separate request. This request includes the isadmin=true parameter, which could potentially elevate the attacker’s privileges or alter data on the server, depending on the application’s functionality.

Transfer Encoding Obfuscation

Transfer Encoding Obfuscation, also known as TE.TE stands for Transfer-Encoding/Transfer-Encoding. Unlike the CL.TE or TE.CL methods, the TE.TE technique arises when both the front-end and the back-end servers use the Transfer-Encoding header. In TE.TE technique, the attacker takes advantage of the servers’ inconsistent handling of  Transfer-Encoding present in the HTTP headers.

The TE.TE vulnerability doesn’t always require multiple Transfer-Encoding headers. Instead, it often involves a single, malformed Transfer-Encoding header that is interpreted differently by the front-end and back-end servers. In some cases, the front-end server might ignore or strip out the malformed part of the header and process the request normally, while the back-end server might interpret the request differently due to the malformed header, leading to request smuggling.

Example: An attacker might send a request with two Transfer-Encoding headers, one with a value the front-end server understands, and another with a value the front-end server ignores but the back-end server understands. This discrepancy can cause the servers to disagree on the request’s boundaries.

Exploiting TE.TE for Request Smuggling

To exploit the TE.TE technique, an attacker may craft a request that includes Transfer-Encoding headers that use different encodings. For example, an attacker sends a request like:

POST / HTTP/1.1
Host: example.com
Content-length: 4
Transfer-Encoding: chunked
Transfer-Encoding: chunked1

4c
POST /update HTTP/1.1
Host: example.com
Content-length: 15

isadmin=true
0

n the above payload, the front-end server encounters two Transfer-Encoding headers. The first one is a standard chunked encoding, but the second one, chunked1, is non-standard. Depending on its configuration, the front-end server might process the request based on the first Transfer-Encoding: chunked header and ignore the malformed chunked1, interpreting the entire request up to the 0 as a single chunked message.

The back-end server, however, might handle the malformed Transfer-Encoding: chunked1 differently. It could either reject the malformed part and process the request similarly to the front-end server or interpret the request differently due to the presence of the non-standard header. If it processes only the first 4 bytes as indicated by the Content-length: 4, the remaining part of the request starting from POST /update is then treated as a separate, new request.

The smuggled request with the isadmin=true parameter is processed by the back-end server as if it were a legitimate, separate request. This could lead to unauthorized actions or data modifications, depending on the server’s functionality and the nature of the /update endpoint.

Walkthrough

The vulnerable environment has ATS (Apache Traffic Server) as the front-end proxy, Nginx as the web server back-end, and PHP processing the dynamic content. Due to differences in how ATS and Nginx prioritise Content-Length and Transfer-Encoding headers, there is a potential for HTTP request smuggling. Start by adding httprequestsmuggling.thm to your /etc/hosts file.

┌──(ishsome㉿kali)-[~/THM]
└─$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	kali


# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

10.10.48.13 httprequestsmuggling.thm

Interacting With the Web Application

The web application can be accessed using the link http://httprequestsmuggling.thm. It features a Home, Login, and Contact form that enables users to access and send feedback to the developer. For demonstration, the submitted queries are saved to the /submissions directory. Below is the screenshot of the application: 

Exploiting the Application

Using Burp Suite Proxy, intercept a request sent to the website’s index. This request will become the baseline we will use to exploit the vulnerable application.

Let’s send this request to Intruder..

We will now copy and paste the following payload in the request box in Intruder.

POST / HTTP/1.1
Host: httprequestsmuggling.thm
Content-Type: application/x-www-form-urlencoded
Content-Length: 160
Transfer-Encoding: chunked

0

POST /contact.php HTTP/1.1
Host: httprequestsmuggling.thm
Content-Type: application/x-www-form-urlencoded
Content-Length: 500

username=test&query=§

Breakdown of the Payload

In CL.TE vulnerability, since the proxy or the front-end prioritises the Content-Length header, 160 bytes of the body is assumed to be the body of the first POST. The front-end thinks this is a single request and forwards it into the pipeline, where the back-end server now prioritises Transfer-Encoding, ending the first POST request at the first 0 size chunk and assuming the second POST is a different request.

Next, we go to the Payloads tab and set the Payload type to Null payloads. Subsequently, on the Payload settings, input 10000 to generate 10000 null payloads.

Next, we go to the Resource pool tab and create a new resource pool. You may follow the screenshot below for the settings.

lick the Start Attack button in your Intruder tab to start the attack.

After a few minutes, check the /submissions website directory to see if the request to contact.php is smuggled containing the request of other users.

Going through these text files, we can check for the password that was appended to the query parameter.

Using the password obtained, we can login to the application and get the flag.

Conclusion

HTTP request smuggling is a vulnerability that arises due to discrepancies in how servers interpret request headers. The core of this vulnerability lies in manipulating the Content-Length and Transfer-Encoding headers, leading to ambiguous requests. These ambiguities can cause servers, especially in setups with front-end and back-end servers to misinterpret the boundaries of each request. This misinterpretation can lead to various malicious outcomes, from bypassing security measures to accessing unauthorized data.

Mitigation and Prevention Strategies

1. Consistent Header Processing: All servers, whether front-end or back-end, should consistently process headers. Any discrepancy can open the door for smuggling.
2. Adopt HTTP/2: HTTP/2 offers a more robust mechanism for handling request boundaries, making it a safer choice against smuggling attacks.
3. Regular Monitoring and Audits: Continuously monitor web server traffic for signs of smuggling attempts and conduct regular audits to ensure server configurations are up-to-date and secure.
4. Educate Teams: Ensure that development and operations teams are well-informed about the risks of request smuggling and the best practices to prevent it.

In conclusion, while HTTP request smuggling presents a significant threat, with the proper knowledge, strategies, and resources, it’s a vulnerability that can be mitigated. Always prioritize security in web application development and operations to ensure the application’s and its users’ safety.