February 9, 2022
By
Christian Folini
(netnea)
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.
January 20, 2022
By
Christian Folini
(netnea)
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.
January 12, 2022
By
Christian Folini
(netnea)
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.
December 22, 2021
By
Christian Folini
(netnea)
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.”
December 16, 2021
By
Christian Folini
(netnea)
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.
December 13, 2021
By
Christian Folini
(netnea)
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.
December 9, 2021
By
Christian Folini
(netnea)
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 As you can see, curl is calling our sandbox with an XSS payload and the sandbox returns the list of CRS rules that the request triggered. If you are unfamiliar with CRS, then the important part is that there are several rules that triggered / detected something. And the total “anomaly score” of 15, which is far beyond the default anomaly threshold of 5 that gets a request blocked for looking like an attack.
November 1, 2021
By
Christian Folini
(netnea)
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.
October 28, 2021
By
Christian Folini
(netnea)
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.
October 6, 2021
By
Christian Folini
(netnea)
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:
