Blogs

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.

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: 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.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: https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc2.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc2.zip 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: https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc1.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc1.zip 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.