Security ModSecurity OWASP Core Ruleset Security Vulnerabilities Leading To DDOS Attacks

eva2000 · May 1, 2019

It seems unpatched vulnerabilities in ModSecurity’s OWASP Core Rule Set can potentially open up web servers to denial-of-service (DoS) attacks known as ReDoS attacks.

Details:

Regular Expression DoS weaknesses in CRS

Unpatched ModSecurity CRS vulnerabilities leave web servers open to denial-of-service attacks !

How can we avoid ReDoS without trust on PCRE limits · Issue #2072 · SpiderLabs/ModSecurity

Set match_limit and match_limit_recursion values to regex variables by airween · Pull Request #2071 · SpiderLabs/ModSecurity

What is ReDoS?
Pattern matching is a CPU intense task and given CRS is heavily based on regular expression patterns, there is a performance problem inherent to many of our rules. Alas, some of the patterns are more CPU intense than others and some have characteristics that steer the processor down a rabbit hole with an almost infinite number of matches if the payload knows about the weaknesses of a particular pattern. Given we are an open source project, our patterns are well known, and Somdev Sangwan created a script that would point him to potentially vulnerable rules, and he would then craft the payloads to kill the server. Well done.
Click to expand...

The ModSecurity OWASP CRS CVEs and if you want to follow the discussions of issues reported by s0md3v who I believe is the one who reported the vulnerabilities ?

CVE-2019-11387

CVE-2019-11388

CVE-2019-11389

CVE-2019-11390

CVE-2019-11391

Centmin Mod doesn't use ModSecurity WAF Firewall by default but Centmin Mod 123.09beta01 has been preparing for optional ModSecurity v3 Nginx Connector support to support a WAF Firewall setup for ages and Centmin Mod's implementation also relies on ModSecurity's OWASP Core Rule Set and uses the current OWASP CRS v3.1.0 which is unpatched for these vulnerabilities. So once OWASP CRS updated release version is available, I will update Centmin Mod 123.09beta01 for the new version. So always run Centmin Mod update command = cmupdate before recompiling/updating Nginx via centmin.sh menu option 4 to ensure you have latest versions/code and when you have set NGINX_MODSECURITY='y' in persistent config file /etc/centminmod/custom_config.inc prior to centmin.sh menu option 4 nginx recompiles, Centmin Mod ModSecurity routine will auto update your OWASP CRS configuration to the latest version with the patches.

A clutch of unpatched vulnerabilities in ModSecurity’s OWASP Core Rule Set has left potentially thousands of web servers open to denial-of-service (DoS) attacks.

ModSecurity is a popular open source web application firewall (WAF) that’s designed to help stop attacks or unwanted behavior against applications by monitoring all HTTP traffic in real time.

The tool works through the implementation of WAF rules. Security professionals can create their own custom rules or deploy existing libraries, such as the free-to-install OWASP Core Rule Set.

It was this open source library that caught the attention of Somdev Sangwan, a 20-year-old researcher from India, who recently disclosed five vulnerabilities in the rule set, each of which has the potential to take web servers offline.

According to Sangwan, the vulnerabilities are all related to the Core Rule Set’s implementation of regular expressions (regex) – strings of texts that allow developers to define search patterns.

Regex exploits leading to denial-of-service are known as ReDoS attacks.

“I have been spending a good amount of time writing ReDoS exploits and studying WAFs lately,” Sangwan explained in a blog post published earlier this week.

“To practice my skills in the real world, I chose [the] ModSecurity Core Rule Set because it has tons of regular expressions, and on top of that these regular expressions are being used by WAFs in the wild to detect attacks.”

The researcher’s intuition paid off, as he found that specially crafted strings could overwhelm the Core Rule Set’s regex engine, causing web servers to grind to a halt.
Click to expand...

CVEs have been assigned to each of the five vulnerabilities, but at the time of writing the flaws remain unpatched in the Core Rule Set.

“They haven’t patched [the vulnerabilities] yet,” Sangwan told The Daily Swig. “I have suggested fixes, but there is still a discussion going on in hopes of finding a robust solution to prevent such attacks in the future.”

The researcher added: “It should be noted that I haven’t released the full exploit strings yet because the vulnerabilities still exist and can be abused.

“The exploits mentioned in my blog are just for the vulnerable parts of the regular expressions and won’t have any effect on an implementation of ModSecurity.”

Sangwan added: “ModSecurity users will be completely safe against these exploits once the suggested changes are made to the rule set and the users update their rule set afterwards.”
Click to expand...

eva2000 · May 1, 2019

Hmm so ModSecurity v3 didn't implement PCRE limits like they did in ModSecurity v2 https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/ and discussed in Set match_limit and match_limit_recursion values to regex variables by airween · Pull Request #2071 · SpiderLabs/ModSecurity !

But looks like Centmin Mod's ModSecurity v3 Nginx connector module implementation has room for improvement by recompiling with PCRE limits !

Though not as simple it seems from Set match_limit and match_limit_recursion values to regex variables by airween · Pull Request #2071 · SpiderLabs/ModSecurity

ModSecurity shares memory space within the NGINX, therefore setting this on ModSecurity will impact on NGINX behavior which has its own constraints. That used to be a problem with ModSecurity v2 especially on php was handling its own limits. That was the main reason why this was not taken into consideration on v3. This subject was discussed back on 2013.

To illustrate: #56, #267, #1176, #1481, and #1290

Setting those values is no guarantee that it will solve the problem. Yet can impact very badly in other modules that use PCRE. The PCRE itself already contains hardcoded limits that can be changed in compilation time. Apparently, those are not enough and lead to the recursion problem. We cannot guarantee that any other module or NGINX itself will not change those values. Potentially leading the less experienced user to believe that he/she is protected when in reality they are not.
Click to expand...

Things are different with ModSecurity 3.x, where the PCRE limit directives have not been re-implemented after the complete rewrite. The reason for this design decision is the assumption, that the underlying webservers do not allow ModSecurity to set the said limits independently. This means ModSecurity developers are afraid their code could re-configure the regex behavior of the whole server. Depending on the webserver implementation, this risk is present with ModSecurity 2.x as well. But the ModSecurity developers wanted to make sure they rule out this possible problem for ModSecurity 3.x. So if you want to change the PCRE limits, you need to recompile ModSecurity 3.x instead of re-configuring them via a directive. We would very much prefer to be able to configure the PCRE match limits at run time, even if this feature is an option that has to be enabled at compile time. So we hope the ModSecurity project will reconsider this.

As a consequence of the limitations with ModSecurity 3.x, there is no easy workaround for the ReDoS weaknesses anymore. You can thus claim that ReDoS is a bigger problem with ModSecurity 3.x than it was with ModSecurity 2.x.

The CRS project does not yet fully endorse ModSecurity 3.x for multiple reasons and this is one of them. So giving ReDoS a 2nd priority so far has been reasonable, as ModSecurity 2.x is the preferred platform to run CRS as of this writing.

But when ModSecurity no longer helps with ReDoS, then the rules need to be improved for the future, and that is clearly the job of the CRS project.
Click to expand...

What can you do in the meantime?
Running CRS is a tradeoff between performance (thus CPU and DoS exposure) and basic protection against many of the security risks described in the OWASP Top Ten. DoS is always a risk with a web server. Most DoS attacks are still executed at the network level, without the attacker paying attention to the existence of a WAF or the application at all. If he or she is taking the time to craft specific application level payloads to kill your server, they are likely to have the knowledge to craft similar payloads to kill your authentication server, your search form, or something else. So CRS is not your only DoS risk and I am sure, it is not the biggest one for most sites.

However, if you really suffer from a ReDoS attack, then monitoring is key and disabling individual rules temporarily will help you. That may look like an insecure practice, but given there are probably over 150 rules active, you are not dropping your shields completely with this. Because the worst thing would be to drop ModSecurity and/or CRS because you think that there is DoS problem you can not live with.

You need to take the attack payload, examine the ModSecurity / CRS behaviour and find out which rules are affected. ModSecurity 2.x is again more helpful in this regard than ModSecurity 3.x. And once you have identified the rule or rules, you disable it like you would write a rule exclusion for a false positive. Ideally you do this via the SecRuleRemoveById directive (to be placed after the CRS include in the configuration).

Our next steps
We are currently reviewing several pull requests dealing with the CVEs in questions. Somdev Sangwan thankfully did not only announce the weaknesses, but he also supported us with finding a remedy.

Once we have accomplished the step of reviewing and integrating the fixes, we plan to publish a CRS bugfix release 3.1.1 soon; ideally with identical behavior, but without the CVEs.
Click to expand...

and Set match_limit and match_limit_recursion values to regex variables by airween · Pull Request #2071 · SpiderLabs/ModSecurity

It is wrong to think that there isn’t a limit. There is. The limit is set by the PCRE library itself. Maybe in the case that you have tested these limits were not low enough. Because it depends on the conjunction of two different things: Input and Regex. Occasionally, the value may be too low depending on the factors listed. Of course all that depends on the factor that you have to accept a regex that might not take the ReDoS scenario into account.

In ModSecurity v2, the limits could be set in different manners:

Considers the default values set on pcre;

Considers the values informed by the user during the pcre compilation;

Considers the value informed ModSecurity compilation;

Considers the value informed during the rules load.

In ModSecurity v3 the user can set the limits by:

Considering the values set on pcre;

Considering the values informed by the user during the pcre compilation.

We have all those different options to set the limits, however, even having those options, there aren't "correct values" per se. Is more about an educated guess. A value that a inexperienced user may not have a clue about - not to mention that we need to support: ARM, Windows, HPUX, Solaris, etc….. That kind of configuration forces the user to consult an expert, it is not too userfriendly. Depending on the scenario, could lead to a circumstance where the user thinks he is protected but in the reality he is not.

As soon as I have some time next week I'll try to dig the historical reasons behind this rationale but we had users complaining that setting pcre limits on PHP was affecting ModSecurity as well. Generally, those limits raise doubt and questions from users.

IMHO we should take the heavy lifting to ourselves and implement something innovative that will make these settings friendlier to our users. We can look at v2 to find what to do and what not to do and take this opportunity to think how we can make it better
Click to expand...

eva2000 · May 2, 2019

Taking my own advice outlined at https://community.centminmod.com/threads/how-to-keep-informed-of-centmin-mod-related-updates.11443/ and using custom Slack channel to follow OWASP Core Rule Set github repo for changes and new release updates at SpiderLabs/owasp-modsecurity-crs.

So everytime a new OWASP CRS release is made or new issue is posted, I'll get a notification in my custom Slack Channel

As you can see I monitor a lot of Github repos. You can do the same with Centmin Mod's Github repo centminmod/centminmod

eva2000 · Jun 27, 2019

Fix for ReDOS attack is out now Announcement: OWASP ModSecurity Core Rule Set Version 3.1.1 – OWASP ModSecurity Core Rule Set

The OWASP ModSecurity Core Rule Set team is pleased to announce the CRS release v3.1.1.

This is a minor release fixing a Regular Expression Denial of Service weakness (CVE-2019-11387) as well as some minor bugs and false positives.

The CVE is only affecting users of the libModSecurity 3 release line and only under special circumstances. However, we advise all users to upgrade to this latest stable CRS release.

We have been notified of 5 ReDoS problems in our rules in April. Upon closer inspection, only 1 of them proved real (the others were found in the naked regular expression, not taking payload transformation and protection mechanisms of the engine into consideration). Once this was established, we had to fix the regex without changing the detection capabilities of the affected rules. And this is what took us so long.

But here we are. This is replacement for 3.1.0 with almost identical behavior (minus the ReDoS and a few other fixes). As always with point releases, there are no new rules and an update should thus be smooth and should not bring any new false positives.

CRS 3.1 requires an Apache/IIS/NGINX web server with ModSecurity 2.8.0 or higher. CRS 3.1 will run on libModSecurity 3.0 on NGINX.
Click to expand...

Centmin Mod 123.09beta01 will be updated with OWASP modsecurity ruleset 3.1.1 within the next few minutes

Log in / Register

Forums

Want to subscribe to topics you're interested in?

Security ModSecurity OWASP Core Ruleset Security Vulnerabilities Leading To DDOS Attacks

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want to subscribe to topics you're interested in?

Security ModSecurity OWASP Core Ruleset Security Vulnerabilities Leading To DDOS Attacks

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.