ModSecurity Denial of Service Details and PoC CVE-2019-19886

In October 2019, Ervin Hegedus and I have discovered two vulnerabilities on the open source web application firewall "libModSecurity"(CVE-2019-19886 from version 3.0.0 to 3.0.3) that could lead to a SecRule bypass and a denial of Service. In this article, I'll describe both vulnerabilities with a PoC on Nginx.

As per the ModSecurity GitHub project libModSecurity is one component of the ModSecurity v3 project. The library codebase serves as an interface to ModSecurity Connectors taking in web traffic and applying traditional ModSecurity processing. In general, it provides the capability to load/interpret rules written in the SecRules format and apply them to HTTP content provided by your application via Connectors.

Thanks to Ervin Hegedus who, like me, is a member of the OWASP Core Rule Set developer team, we've identified some problems on the cookie string parser of the 3.0.0-3.0.3 versions of libModSecurity. To simplify the test process, Ervin has created a stand-alone C++ program called "cookieparse" that reads a cookie string from the first argument and parses it, comparing the results between the "old" and the patched parser version. But let's step back for a moment and focus on cookies.

SecRule Bypass

For the HTTP protocol, the cookie string is a sequence of key=value pairs separated by a ; character.

Even if it looks easy at first, there are lots ways to lead the parser that don't fit with what the standard provides, for example:

What surprised me here is that according to the RFC 6265 a cookie string sent without the = character should be totally ignored. Another interesting thing is:

At point 3 it seems that a cookie could have an empty value or an empty name. I've never considered testing what an application firewall trying to parse a cookie with an empty name would do. Using the cookieparse Ervin discovered that the old parser doesn't include part of the cookie value when the cookie string is something like foo=bar=ciao:

As you can see, for the old parser the value of the cookie foo is bar and not bar=ciao as it should be. That means that it could be possible to inject malicious payload (such as SQL Injection or Cross-Site Scripting) just by putting it after a = character. For example:

The old parser would have completely ignored the XSS payload and it could be possible to bypass a hypothetical rule that checks if a cookie value has malicious content.

DoS Vulnerability

Continuing our bypass tests, what I found after was scared us and it lead us to ask Trustwave for a patch and a security release. As we said before, in a cookie string each name and value are separated by a = and each cookie name/value pairs are separated by a ;. After few tests, I started to put random sequences of ; and = trying to crash it. By sending ;=; nothing has happened but removing the first ; something went wrong. The old parser exited with the following error:

Talking with Ervin about the consequences that this error could have on a webserver running libModSecurity, I've created a docker container with Nginx and the 3.0.3 of libModSecurity. Sending a single request with the cookie header Cookie: =foo I didn't get any response from the webserver, even the response headers part.

By reading the Nginx error_log it becomes clear that my previous request killed the Nginx worker process that wrote the same "out of range" error on the log. From here, it was really easy for me to stuck Nginx just by sending multiple requests with curl and continuously killing all respawning Nginx worker processes with something like:

curl -H 'Cookie: =;' 'http://localhost/?a=[0-10000]' 

Testing it with Nginx that proxy all request to a WordPress, this is what happened:

References

• https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-denial-of-service-details-cve-2019-19886/
• https://coreruleset.org/20200118/cve-2019-19886-high-dos-against-libmodsecurity-3/

If you liked this post, please share and follow me!