ModSecurity and ModSecurity Core Rule Set Multipart Bypasses

During our research of web application firewall evasion issues, we uncovered a flaw in ModSecurity that may lead to complete bypass of the installed rules, in the cases when ModSecurity is deployed to protect the backends where impedance mismatch is not

mitigated. Additionally, a separate flaw in ModSecurity CRS makes the content type checks ineffective, allowing for bypass attacks, when deployed to protect the backends where impedance mismatch is not mitigated.

are tightly coupled with the performance of the engine itself. A comprehensive set of rules for ModSecurity can be obtained from a separate project called

One of the main goals of web application firewalls (WAFs) is to detect attacks against the web applications they are protecting. In the most commonly used deployment modes (e.g., when operating as a reverse proxy), a WAF will terminate the higher layers

of the traffic stream (e.g., the HTTP protocol), but only inspect and pass-through the remainder of the data. In the latter case, WAFs are vulnerable to impedance mismatch issues, where they interpret traffic in one way and the backend application interprets

it in another way. When an impedance mismatch issue exists, the WAF may be vulnerable to evasion attacks.

Impedance mismatch issues are possibly the most difficult aspect of WAF implementation. In many cases, correct deployment requires not only correct implementation in the WAF, but correct configuration and handling of the reported problems by administrators.

Our hope is that this short document, as well as our future research in this area, will shed some light onto this rarely discussed topic of WAF design. We would be delighted if this information is used to raise the effective security in real-life WAF deployments.

Confirmed in ModSecurity 2.6.5; earlier versions likely to be vulnerable

Confirmed in ModSecurity Core Rule Set 2.2.4; earlier versions likely to be vulnerable

block requests that have either of these flags set. For guidance on how to write such rules refer to the recommended default configuration file, which is included with ModSecurity.>

A mismatch between how multipart content is parsed in ModSecurity and PHP enables an attacker to perform a full rule set bypass.

PHP has a very lax multipart/form-data parser. Traditionally, securing ModSecurity against evasion in this parser is where a lot of development time was spent. In 2009, Stefan Esser published an evasion technique that relies on the use of single quotes—which

are supported by PHP but were not supported by ModSecurity at the time—to trick ModSecurity into treating a request parameter as a file. This results in a bypass because ModSecurity uses separate mechanisms for the inspection of request parameter and file

content, and files are often left uninspected.

This issue was addressed in November 2009 in ModSecurity 2.5.11, which started to accept single quotes for quoting. However, upon further examination of the PHP source code, we determined that the fix was not sufficient. PHP will not only allow a single

quote to be used at the beginning of a string, but also at any other position within the string. ModSecurity, on the other hand, expects quote characters only at the first position. With some creativity, the impedance mismatch issue can be exploited to perform

a bypass of the rules.

The issue was confirmed against PHP 5.4.3, but it's very likely that earlier versions can be used too. We are not releasing a proof of concept at this time, but the vulnerability is easy to exploit.

The users of ModSecurity CRS may be protected from this attack, depending on the exact deployment configuration. After the original issue had been reported, a defence-in-depth rule was added to CRS to detect side effects of a bypass attempt. This rule is

effective when CRS is deployed in the traditional blocking mode, but not when anomaly scoring mode is used.

This issue should be addressed in ModSecurity's multipart parser. In addition, we recommend the following:

Short term, improve the recommended default configuration to include the same defense in depth rule as the CRS.

Long term, implement full request body rewriting. If the multipart payloads are fully rewritten according to how ModSecurity understands them, then any missed attack payloads will not be passed through to the backend. Such approach may require more processing,

but we do not believe that this improvement would cause any practical performance issues because multipart content types are infrequent on average.

When the ModSecurity CRS is used to protect certain permissive backend applications, supplying an invalid content type can be used for a complete bypass.

To address unknown content type bypass issues, ModSecurity CRS employs rules that allow only known content types to be used. However, these rules are not strict enough. By default, the CRS will check if the MIME type can be found within the following string

(all one continuous line):

application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf

This check will indeed reject many unknown and invalid MIME types, but it will also accept any substrings that can be found within the above string. In most cases, such invalid MIME types can be used only against a small number of applications. The only

situation where this can be exploited is when attacking applications that expect only certain MIME types known to them (e.g., application/x-www-form-urlencoded) and don't check what actual MIME type is indicated in the Content-Type request header.

the FileUpload library to implement file uploads, so even applications that do not explicitly use upload libraries may be vulnerable. The problem likely affects other web servers that are built on the Tomcat code base. Outside Java, at least one other server-side

framework is thought to be vulnerable to the same problem.

The attack was confirmed against Apache Commons FileUpload 1.2.1, but earlier versions are equally likely to contribute to the bypass in this way.

Ivan Ristic is the original author of ModSecurity. He started the project in 2002, and led it until January 2009. His last code contribution was in 2010. He remains involved through his ongoing work on

ModSecurity Handbook, which is the definitive guide on ModSecurity.

ModSecurity and mod_security are trademarks or registered trademarks of Trustwave Holdings, Inc.