Blogs

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. As of this writing, the engine is PCRE everywhere, but we expect more options in the future.

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:

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.3.0. If you are already running v3.3.0, you can simply extract the files over your existing files.

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.

Introducing msc_pyparser

Let us present msc_pyparser to you. It is a python library that lets you manipulate ModSecurity rules configuration files.

ModSecurity has decent capabilities to manipulate rules at runtime, but msc_parser lets you manipulate the config files themselves. This is useful in many situations and the longer we use it, the more use cases pop up.

We will walk you through four example use cases in this blog post. This is enough to get you inspiration and help you get started.

OWASP ModSecurity Core Rule Set v3.3.0 available

The OWASP ModSecurity Core Rule Set team is proud to announce the final release for CRS v3.3.0.

For downloads and installation instructions, please see the Installation page.

This release packages many changes, such as:

  • Block backup files ending with ~ in filename (Andrea Menin)
  • Detect ffuf vuln scanner (Will Woodson)
  • Detect Nuclei vuln scanner (azurit)
  • Detect SemrushBot crawler (Christian Folini)
  • Detect WFuzz vuln scanner (azurit)
  • New LDAP injection rule (Christian Folini)
  • New HTTP Splitting rule (Andrea Menin)
  • Add .swp to restricted extensions (Andrea Menin)
  • Allow CloudEvents content types (Bobby Earl)
  • Add CAPEC tags for attack classification (Fernando Outeda, Christian Folini)
  • Detect Unix RCE bypass techniques via uninitialized variables, string concatenations and globbing patterns (Andrea Menin)
  • Many improvements to lower the number of false positives and improve attack detections

Important upgrade notes:

OWASP ModSecurity Core Rule Set v3.3.0 Release Candidate 2 available

The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 2 for the upcoming CRS v3.3.0 release. The release candidate is available at:

This release packages many changes, such as:

  • Block backup files ending with ~ in filename (Andrea Menin)
  • Detect ffuf vuln scanner (Will Woodson)
  • Detect SemrushBot crawler (Christian Folini)
  • Detect WFuzz vuln scanner (azurit)
  • New LDAP injection rule (Christian Folini)
  • New HTTP Splitting rule (Andrea Menin)
  • Add .swp to restricted extensions (Andrea Menin)
  • Allow CloudEvents content types (Bobby Earl)
  • Add CAPEC tags for attack classification (Fernando Outeda, Christian Folini)
  • Detect Unix RCE bypass techniques via uninitialized variables, string concatenations and globbing patterns (Andrea Menin)

Important note: The format of configuration setting allowed_request_content_type has been changed to be more in line with other variables. If you had manually changed this setting, then you need to update this configuration setting. Please see the example rule 900220 in crs-setup.conf.example. If you didn’t change this setting, you don’t need to do anything.

Overhauling the CRS Tags

Tagging rules is a great feature of ModSecurity since it allows you to add information to your ModSec alert messages. In my tutorial on Embedding ModSec over at netnea.com, I use the tag feature in the default action to add a tag to every alert message from a given service. I do this as follows:

SecDefaultAction "phase:2,pass,log,tag:'Local Lab Service'"

One of my customers uses a shortcut URI as the tag. So when an alert pops up, the SoC person can click on the tag, the URI is being expanded (redirection service) and she ends up on a wiki page giving her all the infos about a given service with purpose, architecture, host IDs, security classification and contact information.

OWASP ModSecurity Core Rule Set v3.3.0 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.0 release. The release candidate is available at:

This release packages many changes, such as:

  • New rule to detect LDAP injection
  • New HTTP Splitting rule
  • Block backup files ending with ~ in filename
  • Detect ffuf, Semrush and WFuzz scanners
  • Updated exclusion profiles for Nextcloud, WordPress and XenForo
  • Improvements to many patterns to improve detection and lower false alarms

Important note: The format of configuration setting allowed_request_content_type has been changed to be more in line with other variables. If you had manually changed this setting, then you need to update this configuration setting. Please see the example rule 900220 in crs-setup.conf.example. If you didn’t change this setting, you don’t need to do anything.

CRS Repository at New Location

We have successfully migrated our GitHub repository to a new location at

https://github.com/coreruleset/coreruleset

Trustwave SpiderLabs hosted the OWASP ModSecurity Core Rule Set project under their umbrella for many years. They acted as stewards of our project and also directed it via the former lead Ryan Barnett. Yet as a formally independent OWASP project, it is a bit odd to dwell under a commercial entity and for a commercial entity like Trustwave SpiderLabs, it is a bit odd to host a project that they do not control.

CVE-2019-19886 - HIGH - DoS against libModSecurity 3

The ModSecurity 3.0.x release line suffers from a Denial of Service vulnerability after triggering a segmentation fault on the webserver when parsing a malformed cookie header.

All users of ModSecurity 3.0.0 - 3.0.3 should update to ModSecurity 3.0.4 as soon as possible.

ModSecurity 2.x is not affected.

The CVSS score for the vulnerability is 7.5 (HIGH). MITRE lists the vulnerability as CVE-2019-19886 (but as of this writing, it is only reserved).

The OWASP ModSecurity Core Rule Set (CRS) project makes heavy use of unit tests. One of the goals is making sure that all our rules behave as intended on the underlying ModSecurity engine. ModSecurity 2.9 on Apache is our reference platform that passes our expanding list of over 2300 tests.