It happened by one the greatest company on the planet named “Apple”

After finding critical HTTP request smuggling vulnerabilities in three of Apple’s core web applications, a security researcher says that they got $36,000 in bug bounties.

“Smuggling HTTP Request” mean?

An attack method known as HTTP request smuggling involves interfering with the exchange of requests between front-end and back-end servers.

The attacker takes advantage of the weakness by changing the request, so that it includes another request in its body. The Content length and Transfer-Encoding headers are used wrongly to do this. When the attack works, the second request is hidden in the body of the first request and then processed.

HTTP request smuggling is a technique for interfering with the way a website processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users.

What happens in an HTTP request smuggling attack?

Today’s web applications frequently employ chains of HTTP servers between users and the ultimate application logic. Users send requests to a front-end server (sometimes called a load balancer or reverse proxy) and this server forwards requests to one or more back-end servers. This type of architecture is increasingly common, and in some cases unavoidable, in modern cloud-based applications.

When the front-end server forwards HTTP requests to a back-end server, it typically sends several requests over the same back-end network connection, because this is much more efficient and performant. The protocol is very simple: HTTP requests are sent one after another, and the receiving server parses the HTTP request headers to determine where one request ends and the next one begins:

In this situation, it is crucial that the front-end and back-end systems agree on the boundaries between requests. Otherwise, an attacker might be able to send an ambiguous request that gets interpreted differently by the front-end and back-end systems:

Here, the attacker causes part of their front-end request to be interpreted by the back-end server as the start of the next request. It is effectively prepended to the next request, and so can interfere with the way the application processes that request. This is a request smuggling attack, and it can have devastating results.

HTTP Smuggling Vulnerabilities

HTTP request smuggling vulnerabilities arise from the fact that the HTTP protocol provides two ways to specify the boundary of a request:

Content-Length (CL) header-  This figure denotes the length of the HTTP request’s message body in bytes

Transfer-Encoding (TE) header- A hop-by-hop header divides the request body into non-overlapping ‘chunks’ sent independently. A chunk of size zero terminates the message.

An HTTP message can contain both headers, which brings up a conflict in boundary configuration. Vulnerabilities born out of this conflict are:

CL.TE Vulnerabilities

The front-end server uses the Content-Length header while the backend relies on the Transfer-Encoding header. It is possible to craft a malicious request as per the below code:

The front-end server processes the Content-Length header and acknowledges that the message body is 12 bytes long up to the boundary of SMUGGLED CODE. When the backend server receives this request, it processes based on the Transfer-Encoding header, which instructs it to interpret the message with chunked encoding. The first byte is stated to be zero-length, so the server terminates the request. This leaves the SMUGGLED CODE unprocessed, so the backend server treats this as the start of the next HTTP request in the sequence.

TE.CL Vulnerabilities

The front-end server uses the Transfer-Encoding header, while the backend relies on the Content-Length header. The hacker can then perform a request smuggling attack using malicious code similar to:

The front end treats the message body as using chunked encoding. It processes the first chunk size as 6 bytes long until the line after SMUGGLED CODE. The backend server then receives and interprets the request as 4 bytes long, up to the start of the line after 6. The remaining bytes starting with SMUGGLED CODE are not processed, so the server treats them as the start of the next incoming HTTP request.

TE.TE vulnerabilities

Both servers use the Transfer-Encoding header, but attackers can induce one of the servers not to process the request by obscuring it. Some ways to obfuscate the Transfer-Encoding header are shown below:

The attacker specifies an obfuscated transfer-encoding header so that the back or front end is induced not to interpret it. The hackers then proceed with an attack similar to those explained in CL.TE and TE.CL vulnerabilities.

Types of HTTP Request Smuggling Attacks

1. Bypassing Client Authentication

During authentication, the client uses a “common name (CN)” to verify the legitimacy of the server responding to their requests. The authentication component passes relevant certificate details to the backend in an HTTP header. The front-end server appends a header containing the CN to incoming requests as below:

Users typically hide these headers, so the backend implicitly trusts the details provided. HTTP request smuggling type of attack involves sending specific malicious headers and values, using which attackers can bypass security controls. By configuring the front-end servers to overwrite these headers, hackers usually hide the smuggled requests from the front end so that they reach the backend unaltered.

• Exploiting Reflected XSS Using HTTP Request Smuggling

HTTP request smuggling simplifies Reflected XSS exploits since it does not require interaction with legitimate users. The attacker only needs to create a smuggled request with the XSS payload, which will be processed with the next application user’s request. Assuming an application is found to contain the Reflected XSS vulnerability in the Running-Time header, the attacker can craft an HTTP request smuggling attack.

• Capturing Other User Requests

Attackers can use HTTP request smuggling to access the details of authorized users’ requests in applications that allow for the storage and retrieval of textual data. The components extracted include session tokens, cookies, and other sensitive data submitted by the client. The attacker creates a smuggled request to submit data to the storage function, with the data parameter at the bottom of the request. The backend appends the subsequent legitimate request with the smuggled request, resulting in the successful processing and storage of the smuggled request. The attackers can then retrieve this stored data using the normal retrieval function.

• Mitigating HTTP Request Smuggling Vulnerability

Some measures to mitigate HTTP smuggling include:

Use a web application firewall to block the malicious URL and IP addresses

Normalize abnormal requests, and close the TCP connection for persistent ambiguous requests

Disable any performance optimizations that use the Content-Length and Transfer-Encoding header in the backend server

Avoid using a Content Distribution Network or reverse proxy server whenever possible

With an HTTP smuggling vulnerability, the impacts of a successful attack are critical. Attackers can gain access to user accounts and sensitive information. Protect your web application and data assets by trying the Crash Test Security Suite.

How to Prevent HTTP Request Smuggling Attacks?

Some ways to prevent HTTP request smuggling attacks include:

Prioritize Transfer-Encoding over Content-Length Headers

If the request contains TE and CL headers, the server should be configured to prioritize the transfer encoding header over content length. TE headers can cover static and dynamic requests, so using them for requests with two headers is the first line of defence against CL.TE and TE.CL attacks.

Use the Latest HTTP Protocol

Use HTTP/2 in all deployments as it comes with a robust, built-in mechanism to evaluate the length of HTTP requests. If HTTP/2 is used both in the front-end and back-end servers, it provides an innate immunity to request smuggling.

Secure Logged HTTP Traffic

Ensure that HTTP logs are only accessible to administrative users. This restricts attackers from accessing unintended parts of the HTTP requests, making it difficult to insert a malicious request into a legitimate user request.

Reject Requests with Doubleheaders

Any request that contains TE.CL, CL.TE and TE.TE headers should get an HTTP 400 error response. This error informs the client that the server will not process the HTTP request due to malformed request syntax. This enforces the consistent interpretation of HTTP headers in both the front-end server and back-end server.

Use a Vulnerability Scanner

Vulnerability scanners can identify poorly configured HTTP requests and help mitigate attacks before they occur. The Crash-test Security Suite includes an automated security vulnerability scanner that enforces continuous testing to reduce the risk of attacks on web applications. Continuous testing helps QA and security teams to identify TE.CL, CL.TE and TE.TE vulnerabilities before attackers can leverage them for attacks.

Design Frontend and Backend to reject the vulnerable request.

• Make the front-end server understand confusing request
• Make the backend server reject the unclear request and disconnect from the network
• Reuse of the backend connection should be disabled
• Use the same web server software for the front and back ends
• Prefer a WAF with built-in mitigation for detecting unusual requests.

Please reach out to security@novaturetech.com for any clarification. We can take care of the Security and let you focus on your business

Author: admin   | Posted On: 25th April 2023   | Category: Article