Over the past few months there has been a lot going on with ModSecurity. There was libModSecurity (aka 3.0) release which was covered in details in a recent blog post by Lead Developer @zimmerle. There was also two recent presentations / demos by the core team at BSides Toronto and BlackHat Arsenal Europe.
Finally, both ModSecurity and the Core Rule Set (CRS) also had some notable achievements such as being nominated to the DINACon Award and winning the German Open Source Business Award (OSBAR) which are results of efforts from CRS project leaders.
It's also worth mention that the new edition of OWASP Top Ten features ModSecurity and the CRS under A10: Insufficient Logging & Monitoring under "How to Prevent":
"... There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting."
These are some of the great achievements from the community that supports and contributes to ModSecurity and CRS in a number of ways. Congratulations to all! :)
Also, and as usual, in the last few weeks the SpiderLabs WAF team have also released new commercial rules for ModSecurity Web Application Firewall (WAF) v2.9 and above. These rules' purpose is to protect against new emerging attacks that target vulnerabilities in public software.
For this release we are highlighting virtual patches for Oracle WebLogic (CVE-2017-10271 / CVE-2017-3506) and JBoss RCE (CVE-2017-12149). These issues could allow an attacker to perform Remote Code Execution attacks.
The Oracle WebLogic issues happens because of unsafe XML deserialization using Java XMLDecoder in the CoordinatorPortType web service. Attackers may send crafted XML documents to the web service which causes WebLogic to deserialize it allowing an attacker to construct arbitrary Java objects and invoke their methods resulting in remote code execution (RCE)
The JBoss issue takes place at the HTTP Invoker service that provides HTTP and RMI access. It's also an unsafe deserialization that happens in the ReadOnlyAccessFilter.java file which receives an object and calls it on the POST data sent by the user without doing validations on the input. This allows sending a maliciously crafted serialized object to the server that when deserialized would trigger the RCE.
These vulnerabilities ranks with a heightened level of risk as there are known exploits in the wild allowing remote and unauthenticated attacks possibly leading to full server compromise by chaining it with other techniques.
ModSecurity Rules from Trustwave® SpiderLabs® include custom virtual patches for public vulnerabilities.
Release Summary