Please note that this was a script using ten threads and NGINX runs on 8 cores. Your browser does not support the video tag. This is a python script killing an NGINX server running ModSecurity v3 and CRS3. While we are not sharing an exploit, here is a video demonstrating a proof of concept attack. Video of the PoC (we are not sharing an exploit though)
ModSecurity v3.0.4 (patch for this version available).The vendor did not publish a new release, but there is a patch that brings back the former behavior.ĬVSSv3: 7.5 HIGH – Exploitability Metrics:ĬWE-400: Uncontrolled Resource Consumption Known Affected Software Configurations: The vendor Trustwave Spiderlabs dropped this functionality for ModSecurity v3.
The defense is handicapped due to the absence of the SecRequestBodyNoFilesLimit directive. It also fills the TX variable space beyond the documented limit of 10 instances. This results in a DoS for existing non-anchored regexes containing the “capture” action. ModSecurity v3.0.x silently changed the behavior to global matching. While ModSecurity v2.x used to quit the execution of a regular expression after the first match. The combination of a non-anchored regular expression and the ModSecurity “capture” action can be exploited via a specially crafted payload. ModSecurity v3.0.x is affected by a Denial of Service vulnerability due to the global matching of regular expressions.
The vendor Trustwave Spiderlabs did not release an update yet. This affects all releases in the ModSecurity v3 release line. The OWASP ModSecurity Core Rule Set (CRS) team has identified a Denial of Service vulnerability in the underlying ModSecurity engine.