Vulnerabilities in open source WAF ModSecurity

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.

ModSecurity is a popular and widely deployed open source web application firewall engine. By design, ModSecurity does not include any security logic. The recommended configuration contains only a couple of rules that 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 ModSecurity Core Rules.

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.

Vulnerable versions

• 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.

Users are advised to upgrade to ModSecurity 2.6.6 and ModSecurity Core Rule Set 2.2.5, which are thought to fix the issues documented here. Further, those who are not deploying the CRS should check that in their configuration they have rules that check REQBODY_ERROR and MULTIPART_STRICT_ERROR, configured to 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.

Problem #1: Multipart bypass in ModSecurity with PHP in the backend
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.

Problem #2: Content type bypass in ModSecurity CRS with certain backends
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 attack was confirmed against Apache Commons FileUpload 1.2.1, but earlier versions are equally likely to contribute to the bypass. Starting with the Servlet 3.0 specification, file uploads are supported natively, without the need to use a separate library. The Tomcat web server bundles 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.

Credit
The new vulnerabilities discussed here were discovered by Ivan Ristic, from Qualys Vulnerability & Malware Research Labs (VMRL).

Notices

• 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.
• At Qualys, Ivan Ristic is part of a team working on IronBee, which is also an open source web application firewall.
• ModSecurity and mod_security are trademarks or registered trademarks of Trustwave Holdings, Inc.