Blogs

Update on CRS 4.0 release delay

Dear all,

A few months ago we happily announced the first Release Candidate for Core Rule Set 4.0.

Our original plan was to finish the 4.0 release as fast as possible. However, we found ourselves in a unique situation for our project.

After the Release Candidate, a large CRS user organized a CRS Bug Bounty event, where advanced WAF hackers were tasked to bypass our ruleset to earn prizes. Since a similar earlier event did not uncover any findings, we were expecting to only get a small number of bug reports. But the hackers turned out to be amazing and created more than 100 malicious payloads that bypassed our detection!

Core Rule Set v4.0.0 Release Candidate 1 available

The OWASP ModSecurity Core Rule Set team is proud to announce the Release Candidate 1 for the upcoming CRS v4.0.0 release. The release candidate is available from our installation page; see also the upgrade notes on that page.

CRS 4 contains many important changes, such as:

• A plugin architecture for extending CRS and minimizing attack surface. Application exclusion sets and less-used functionality have been migrated from the CRS to plugins. (See our plugin registry for the extensive list of existing plugins.)
• Early blocking
• Granular control over reporting levels
• All formerly PCRE-only regular expressions have been updated to be compatible with Re2/Hyperscan WAF engines
• We now publish nightly packages of the development branch
• We refactored and renamed the anomaly scoring variables and paranoia level definitions
• HTTP/0.9 support has been dropped to resolve false positives.

CRS 4 contains many new detections:

CRS names Felipe Zipitría as third Co-Lead

The OWASP ModSecurity Core Rule Set project is very happy to announce Felipe Zipitría as a new and third Co-Leader. Felipe joins Walter Hop and Christian Folini in his new role.

Felipe Zipitría holds a master of computer science from the University of the Republic in Montevideo, Uruguay. He worked as a system administrator for the faculty of engineering for several years and also lectures on security at the University.

The Case for Early Blocking

Early Blocking is a feature that CRS will deliver with the next major release, probably Spring 2022. You can use it immediately when deploying the latest dev / nightly build. This blog post will explain the feature, how to enable it and why it is very useful.

What is Early Blocking?

ModSecurity, the engine below CRS, processes requests in multiple phases. The phase 1 is the request header phase, the phase 2 is the request body phase. Normal blocking of attacks happens at the end of phase 2. Now if CRS identifies an attack in phase 1, it will wait until the end of phase 2 to block the request. That is obviously a waste of resources (even if that waste is relatively small). But it is also a missed chance to finish off an attacker in time. But I’ll come to that later.

Introducing the Fake Bot Plugin

In one of my previous blog posts, I introduced the CRS plugin mechanism that we are rolling out for the next major release. Check out the blog post to learn how you can start using plugins immediately, without waiting for the next release (hint: really simple).

Several plugins are already available. One of them is the Fake Bot Plugin that I put into production recently. It’s a neat little plugin written by CRS dev Azurit / Jozef Sudolsky and it can serve as a perfect illustration of the capabilities of CRS plugins.

Comprehensive View of the WAF Market From an Open Source Perspective

The log4j mess allowed everybody to see security shortcomings of the IT industry on a big scale. It also shed light on the shortcomings of the WAF market, a highly contested field with a myriad of commercial players and - well - us, the OWASP ModSecurity Core Rule Set (CRS), the only general purpose open source Web Application Firewall option.

This blog post will describe the WAF market from a CRS perspective, it will explain what we see as lacking and how we plan to improve the situation.

The CRS Plugin Mechanism

Plugins are not part of the CRS 3.3.x release line. They will be released officially with the next major CRS release 4.x. In the meantime, you can use them with one of the stable releases by following the instructions below.

What are Plugins?

Plugins are sets of additional rules that you can plug in to your web application firewall in order to expand CRS with complementary functionality or to interact with CRS. Rule exclusion plugins are a special case: these are plugins that disable certain rules to integrate CRS into a context that is otherwise likely to trigger certain false alarms.

Talking about ModSecurity and the new Coraza WAF

It’s time to talk about the ModSecurity engine and to introduce you to Coraza, a new contender on the WAF front. Any rule set is nothing without a WAF engine to run it, so even if our project is focused on the rules, we need to look at the underlying engine(s) from time to time.

On August 26, 2021, Trustwave, the owner of ModSecurity, announced the end of Support for ModSecurity for 2024 in a blog post. The blog also states that Trustwave plans to “let the open-source community continue the project.”

Public Hunt for log4j / log4shell Evasions / WAF Bypasses

We have been updating our detection for the infamous CVE-2021-44228 vulnerability and its siblings for several days now. With the new experimental rule 1005, we think we really have decent detection capabilities now. Read up on this development in the separate blog post CRS and Log4j / Log4Shell / CVE-2021-44228.

Right before the log4j CVE was published, we took up our CRS Sandbox that lets you test payloads against various CRS installations.

CRS and Log4j / Log4Shell / CVE-2021-44228

This is an evolving blog post with infos about the role of CRS in defending against the log4j vulnerabilities that threatens quite all logging JAVA applications. We believe the mitigations and rules suggested below will have you covered up to and including CVE-2021-45105.
In January 2022, we have consolidated our knowledge into a pull request with new rules to be merged into CRS for the next major release. The pull request can be applied to your existing installation for immediate use of the new rules.