Announcing CVE-2021-35368: OWASP ModSecurity Core Rule Set Bypass

How did I identify this vulnerability in a popular security product, and what does it mean for users?

In early June 2021, I identified a request body bypass vulnerability in the OWASP ModSecurity Core Rule Set (CRS). Loadbalancer.org appliances themselves are unaffected.

Here's the official OWASP CRS announcement and the Mitre CVE record.

The vulnerability affects all releases of the Core Rule Set version 3. All CRS 3 installations that include the default predefined rule exclusion files are impacted. The OWASP ModSecurity CRS team has released fixes for CRS versions 3.1, 3.2, and 3.3. Users of CRS 3 are encouraged to upgrade to a fixed version as soon as possible (3.1.2, 3.2.1, or 3.3.2).

What to do

Customers of other load balancer or WAF vendors that use the OWASP ModSecurity Core Rule Set should check whether they are vulnerable and if the fix is available as an update from their vendor.

The Core Rule Set version 3 comes with a series of predefined exclusion rule files. These files simplify the process of putting a CRS enabled WAF in front of certain common web applications, such as Wordpress and Nextcloud. This is achieved by disabling certain rules from the Core Rule Set for locations and parameters that are known to cause false positives (false alarms) with the CRS WAF rules.

The vulnerability lies in one of these exclusion rule files. A missing helper rule means that a subset of rule exclusions are applied unconditionally, regardless of whether the exclusion rules in question are enabled in the CRS configuration. An attacker could exploit the unconditional rule exclusions by crafting an HTTP request to match one of these exclusions. The Core Rule Set can be tricked in this way into disabling ModSecurity’s request body processing for such a request. This means that a message body can contain arbitrary malicious content, completely bypassing the attention of ModSecurity and the CRS.

How I found it

I found this vulnerability as part of the thorough due diligence we always undertake at Loadbalancer.org before upgrading to any new software.

In this instance, I was performing due diligence as part of an ongoing project to implement the CRS v3 across the Loadbalancer.org product line (more news on this exciting project coming soon in future blog posts!).

This experience has been yet another reminder of how free and open-source software is awesome. Having the freedom to read and audit the CRS source myself is what allowed me to find this vulnerability. Proprietary software, on the other hand, is an inscrutable black box: you have no choice but to blindly hope and trust that it’s secure!

The importance of responsible disclosure

If something looks odd and you think you can exploit it, don’t just assume something is intentional and that you’ve missed something. There’s no harm in checking with a developer, just in case you have found something important!

If you do find a potential vulnerability then it’s important to disclose it responsibly with the developers. This provides time to confirm (or disprove) the issue, develop and test a fix, and prepare releases and announcements.

I'd like to thank the OWASP CRS team, who were very quick to acknowledge and investigate this issue. Thanks to them for their prompt and helpful communication.

Everyone benefits

We take free and open-source software seriously at Loadbalancer.org. As part of the open-source community, we actively engage and feedback into it to improve the stability, reliability, and security of products.

This experience helps inform our development model and create highly performant load balancing solutions.

Discovering a CVE-worthy vulnerability has been an interesting new experience. I can’t wait to see what my next challenge will be!