Blogs

Introducing the CRS Sandbox

The OWASP ModSecurity Core Rule Set project is very happy to present the CRS Sandbox. It’s an API that allows you to test an attack payload against CRS without the need to install a ModSecurity box or anything. Here is how to do this:

$ curl -H “x-format-output: txt-matched-rules” “https://sandbox.coreruleset.org/?search=<script>alert('CRS+Sandbox+Release')</script>"
941100 PL1 XSS Attack Detected via libinjection
941110 PL1 XSS Filter - Category 1: Script Tag Vector
941160 PL1 NoScript XSS InjectionChecker: HTML Injection
949110 PL1 Inbound Anomaly Score Exceeded (Total Score: 15)
980130 PL1 Inbound Anomaly Score Exceeded (Total Inbound Score: 15 - SQLI=0,XSS=15,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 15, 0, 0, 0

CRS Developer Retreat 2021

The OWASP ModSecurity Core Rule Set team met for a one week developer retreat in the Swiss mountains to hack away at CRS together. We worked on several larger projects and ran seven additional workshops, all documented on our GitHub wiki.

Why Switzerland? Switzerland is an expensive place, but most of our active developers live in Europe and then Switzerland becomes central. And we found the Hacking Villa ran by local ISP Ungleich. Villa is a funny description, since it’s more like a very old alpine hostel equipped with the latest IPv6. But the main reason we settled on this offering was the great price that hotels in European cities could not compete with (and then of course the 10Gb/s fiber!) If you are looking for a cheap, no-bullshit offering to host a camp, then look into the Hacking Villa.

Working with Paranoia Levels

Paranoia Levels are an essential concept when working with the Core Rule Set. This blog post will explain the concept behind Paranoia Levels and how you can work with them on a practical level.

Introduction to Paranoia Levels

In essence, the Paranoia Level (PL) allows you to define how aggressive the Core Rule Set is. Very often, I explain this with the help of a dog. In the default installation, you get a family dog that is really easy going. It is a breed that causes no trouble. Bring your neighbour’s kids and have them pull the dog by its tail and he won’t bite.

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. That means you can disguise a classical path traversal using dots as follows:

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. A backend vulnerability can thus be exploited despite being protected with the CRS Web Application Firewall rule set when an application server accepts additional path info as part of the request URI. All known CRS installations that offer the predefined CRS rule exclusion packages are affected. This applies to end-of-life CRS versions 3.0.x, 3.1.0, 3.1.1 as well as the currently supported versions 3.2.0 and 3.3.0. Integrators and users are advised to upgrade to 3.1.2, 3.2.1 and 3.3.2 respectively.

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. The project was also motivated by the fact that it’s now a common thing to rely on machine learning in web application security, like big WAF vendors such as F5 or Fortinet do.

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. NGINX provides a number of solutions bundled with NGINX OSS, including web application firewalls (WAFs), a Kubernetes Ingress Controller, a Service Mesh, and a controller with Application Delivery Controller (ADC), Application Security and API-Management capabilities.

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.