Security products have their own security issues, which can affect products that they were designed to secure. It’s not a recursive loop, but the reality. WAFs there are not an exclusion.
You can remember CloudFlare self-DoS that happened last year (https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/) because of an issue in RegExp signature they applied. Or Imperva’s data breach that disclosures API keys of their clients https://krebsonsecurity.com/2019/08/cybersecurity-firm-imperva-discloses-breach/
The latest thing with ModSecurity (https://www.secjuice.com/modsecurity-vulnerability-cve-2019-19886/) is another one example of how it’s possible to shut down an entire webserver by just a little cookie. I mean the COOKIE header inside HTTP request. Funny, that theMiddle is initially tried by find a bypass for cookie parser itself, to put SQLi, XSS, RCE, and other attacks there avoiding blocking at the WAF side.
The DoS exploit they found is simple and dangerous at the same time. Basically, any cookie value with an empty name will cause the crash. Like this:
curl -H 'COOKIE: =crashyou;' http://localhost
Since some of our customers are still using ModSecurity for some applications, and Wallarm for API security, multi-tenancy, and other cases, we decided to release a virtual patch on it. Yes, this is strange a bit to protect WAF by another one WAF, but the mission is so critical when it’s possible to crash the server by a single request.
From the GUI, it looks like HEADER COOKIE, than COOKIE parser applied to the value there, and an empty key as the value.
From the wconsole shell, available for standalone customers, it seems like this:
HintStorage.create(type:'vpatch', action: [], clientid: <ID>, point: Proton::Point.new([[:header, "COOKIE", :cookie,""]]), attack_type: "any" )
As a result of applying this virtual patch, requests with an empty COOKIE name with some value or without it will be blocked.
So, that’s pretty much everything for today. Stay secure with Wallarm!
