Imperva Cyber Community

 View Only

Imperva Product Updates - Imperva Mitigation of HTTP Request Smuggling attacks

By Ira Miga posted 01-14-2020 09:02

  


Introduction

Imperva Release Notes provide information on changes and enhancements to our Cloud WAF product in each release. In October 2019 a series of changes were implemented to protect Imperva Cloud WAF customers against HTTP Request Smuggling attacks (learn more here). Further updates have been made over the past 60 days; these changes have also been detailed in in Release Notes. This article will explain recent updates, detail the attack technique that precipitated them and explain why it is important to be protected against such attacks.

 

What is HTTP Smuggling?

An HTTP Request Smuggling attack includes HTTP requests aiming to cause two devices in a chain of HTTP servers to see different sets of requests. This allows the hacker to smuggle a request to one device without the other device being aware of it. While this hacking technique was discussed widely in 2005, today there are still attempts to use HTTP request smuggling in order to make Web Application Firewall miss the request.

Recent changes to Imperva Cloud and On-Premises WAF include additional mitigation rules to insure that such attacks fail.

 

How do these vulnerabilities arise?

These attacks involve placing both Content length and Transfer Encoding headers into a single HTTP request and manipulating them so that the front-end and back-end server process the request differently. Both Cloud and On-Prem WAFs act as the "front-end" server, and the origin server acts as the "back-end“. The thing is that there are 2 different ways according to RFC to specify where the request ends: Content-Length and Transfer-Encoding header. The Content-Length header is straightforward: it specifies the length of the message body in bytes:

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

q=smuggling

The Transfer-Encoding header can be used to specify that the message body uses chunked encoding. This means that the message body contains one or more chunks of data. Each chunk consists of the chunk size in bytes (expressed in hexadecimal), followed by a newline, followed by the chunk contents. The message is terminated with a chunk of size zero.

POST /search HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

The exploit:

Since both headers are allowed, it is possible to use both of them in the same request to specify its boundaries.If two or more servers that process this request are chained together, there is a possibility one of the servers will process these headers differently than the other/s. For example, some servers do not support the Transfer-Encoding header or treat it differently if it is obfuscated in some way. If the front-end and back-end servers behave differently in relation to the Transfer-Encoding header, then this may cause conflicts in the boundaries between successive requests, leading to request smuggling vulnerabilities.

 

How does Imperva protect against HTTP Request Smuggling?

Whereas in the past such requests were passed on to the customer origin servers, today our Cloud  and On-Premises WAF block requests with header anomalies with a request parsing error (Error Code 3 – “There was an error in processing the request”).

The following requests are blocked:

  1. Multiple Content-Length headers with different values.
  2. Multiple Content-Type headers with different values.
  3. Spaces or tabs before the first header.
  4. A header in the following format: <header-name><header-value>, with no separating colon.
  5. \r or \n in a header name.
  6. Transfer-Encoding: chunked and Content-Length headers are both specified, but the total body length (raw, including chunking metadata) does not match the Content-Length value.
  7. The Transfer-Encoding header contains an illegal value.
  8. Multiple Transfer-Encoding headers with different values.

 

Examples of requests blocked by our WAF after the recent implementations:

Duplicate Content Type:

 

HTTP/1.1 200
Server: nginx/1.16.1
Date: Wed, 06 Nov 2019 01:46:00 GMT

Content-Type: application/octet-stream


Connection: keep-alive
Content-Type: text/plain

.

.

.

 

Content-Length inconsistent with Transfer-Encoding:

 

POST /w HTTP/1.1
Accept: application/json; charset=utf-8
Content-Type: application/json; charset=UTF-8
Content-Length: 62719

.

.

.
Transfer-Encoding: chunked
User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-J510MN Build/MMB29M)

.

.

 

Some our customers were not aware that many of their legitimate end-users send requests with multiple Content–Length headers or insufficient Transfer-Encoding and Content-Length headers.

In the event these customers would like to maintain existing configuration, specific vulnerability enforcements can be disabled until the end-users are notified of this change in.

 

 

 

 


#CloudWAF(formerlyIncapsula)
#On-PremisesWAF(formerlySecuresphere)
4 comments
993 views

Permalink

Comments

Ira Miga
01-11-2021 08:34

Hi @Cezmi Cal,

Yes, these rules are in the HTTP Protocol Validation Policy, which prevents protocol exploits.
To protect against SQL injection and other types of attacks, where the malicious content appears in data, we use Application-level policies.

Cezmi Cal
01-11-2021 06:26

Hi @Ira Miga,

Thanks for response. As I understand from the article and your response, all rules are based on HTTP Header values, not body.

If someone tries SQL injection with bypass methods like following link: https://www.dionach.com/blog/fun-with-sql-injection-using-unicode-smuggling/, I think any of these rules will not match with this kind of payload, right?​
Best Regards,

Ira Miga
01-10-2021 08:23

Hi, @Cezmi Cal​,

You are right about the first 2 requests, starting version 12.6 and 13.6 Redundant HTTP Headers changed to be enabled by default.
About request number 3 - starting version 14.1 - blocked by default, since preceding spaces in header names are no longer treated as a sign of header continuation and the line is no longer concatenated to the previous header value.
Number 4 blocked by Malformed HTTP Header Line enabled by default, same as number 5.
Number 6: Blocked by policy "Discrepancy between transfer-encoding and content-length".
Number 7: Blocked by policy "HTTP Request Smuggling using Transfer-Encoding with non-RFC value“ (ADC) - Recommended for Blocking for Web Applications.
Number 8: It's correct, starting version 14.1.
Best,

Cezmi Cal
01-08-2021 08:23

Could anyone also share the matching rules for following attacks/requests for On-Prem WAF?

  1. Multiple Content-Length headers with different values. (I think "Redundant HTTP Headers" rule under HTTP Protocol Validation Policy will match this attack.)
  2. Multiple Content-Type headers with different values. (I think "Redundant HTTP Headers" rule under HTTP Protocol Validation Policy will match this attack.)
  3. Spaces or tabs before the first header.
  4. A header in the following format: <header-name><header-value>, with no separating colon.
  5. \r or \n in a header name.
  6. Transfer-Encoding: chunked and Content-Length headers are both specified, but the total body length (raw, including chunking metadata) does not match the Content-Length value.
  7. The Transfer-Encoding header contains an illegal value.
  8. Multiple Transfer-Encoding headers with different values. (I think "Redundant HTTP Headers" rule under HTTP Protocol Validation Policy will match this attack.)

Thanks,