Blogs

CRS protecting users from Apache CVE-2021-41773

Version 2.4.49 of the Apache webserver is affected by a path traversal vulnerability. This caught a lot of people on the left foot. Well not those who protect their services with CRS. CRS has your back for this new exploit too - as very often. There are a lot of proof of concept exploits for this vulnerability around now. All proof of concepts I saw work via hex encoding the dot-character as %2e.

CVE-2021-35368 - CRS Request Body Bypass (Update)

There is a severe security issue in our rule set. It has been present since the release of CRS 3.1.0 and was recently brought to our attention. Here is the official advisory that we are also publishing as CVE-2021-35368 via MITRE (as usual, MITRE will take a few days until they publish this). Offical Advisory for CVE-2021-35368 The OWASP ModSecurity Core Rule Set (CRS) is affected by a request body bypass that abuses trailing pathname information.

Upcoming CRS Security Releases

A security problem with the OWASP ModSecurity Core Rule Set has been brought to our attention recently. The CRS team is now working on a fix that will be released on Wednesday as 3.1.2, 3.2.1 and 3.3.2. We will make sure to keep the changeset of these bugfix releases minimal in order to allow fast patching. MITRE has assigned the number CVE-2021-35368 to this weakness. We consider the severity of the vulnerability to be HIGH.

A new attempt to combine the CRS with machine learning

The following is a contributing blog post by Floriane Gilliéron. You can reach Floriane via firstname dot lastname at gmail.com. My Master Thesis from EPFL tackled the challenge of using machine learning to improve the performance of a ModSecurity web application firewall, used with the OWASP Core Rule Set. The initiators of the project were concerned about the high number of false alerts (around 90 per day) issued by their WAF, which from a business point of view did not allow the use of blocking mode.

Introducing the Dev on Duty Program

CRS is an open source project that struggles to address the issues reported by the community just like so many other open source communities. Everybody enjoys to develop new features (rules!), but grinding away at solving false positives is not necessarily a favorite past time for us. We are falling behind with providing solutions to reported shortcomings of the rule set, we lose sight of feature requests and unfortunately there are even queries that go unanswered.

Announcing a partnership with NGINX

The OWASP ModSecurity Core Rule Set (CRS) project is proud to announce its first Gold Sponsor: NGINX. CRS is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls that is distributed under an Open Source license. Dubbed the first line of defense, CRS is the most widspread WAF rule set on the internet protecting more than 100 TBit/s of traffic globally. NGINX is the Open Source (OSS) web server, reverse proxy and API gateway, that today powers over 400 million websites.

Disabling Request Body Access in ModSecurity 3 Leads to Complete Bypass

If you are running ModSecurity 3 with request body access disabled, then I have some bad news. Please sit down, this will be a while. If you are running ModSecurity 2, or you give the engine access to the request body, then you are not affected. But maybe you want to read this post nevertheless. I’ll be discussing a new ModSec3 vulnerability an upcoming new CRS feature and some fundamental problems affecting existing ModSecurity rule sets.

Introducing msc_retest

Debugging CRS and more generally debugging ModSecurity can be nasty. False Positives are the worst, but also nagging performance problems can spoil the fun. Sometimes you have network problems or the whole architecture is botched. But equally often it’s simply your server or ModSecurity that’s misbehaving. This blog post is about msc_retest, a small family of tools that lets you performance test the regular expression engine used inside various ModSecurity versions.

OWASP ModSecurity Core Rule Set v3.3.1 Release Candidate 1 available

The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 1 for the upcoming CRS v3.3.1 release. The release candidate is available at: https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.zip This is a maintenance release, containing the following changes: Run rules as early as possible, by decreasing phase:2 to phase:1 and phase:4 to phase:3 where the variables allow it (Ervin Hegedüs) Add early blocking mode (tx.blocking_early) to block at the end of phase:1 and phase:3 (Christian Folini) There are no changes to attack detections, so this release is mostly a “drop-in” replacement for our former release 3.

CVE-2020-15598 - ModSecurity v3 Affected By DoS (Severity HIGH)

The OWASP ModSecurity Core Rule Set (CRS) team has identified a Denial of Service vulnerability in the underlying ModSecurity engine. This affects all releases in the ModSecurity v3 release line. The vendor Trustwave Spiderlabs did not release an update yet. However, we are providing users with a patch for ModSecurity and a workaround if they can not patch. Likewise, we are coordinating the patching with the Linux distributors. This blog post tries to give you a comprehensive overview of the problem with all the resources you need to cope with the situation.