How we discovered and patched ModSecurity DoS CVE-2021-42717

This article describes how we found a Denial of Service vulnerability on the ModSecurity JSON body processor (CVE-2021-42717) and how Mithril’s Developers Team patched it waiting for the official patch delivered by the ModSecurity developer team. If you want more information about Mithril Web Application & API Protection, visit What Mithril WAAP is?.

 

What ModSecurity is?

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 ModSecurity SecRules format and apply them to HTTP content provided by your application via Connectors. More information at https://github.com/spiderLabs/ModSecurity

 

Introduction

Web Application Firewalls usually need to understand a huge variety of HTTP request formats, especially when they come with a body such as a form login, or a contact form, or a file upload. Web applications can handle all these functionalities by making users send the body part in different formats or “content-type” like x-www-form-urlencoded that needs a key-value sequence string like key=value&key2=value or json that should be something like {"key":"value","key2":"value"}.

When an HTTP request comes with one of the above content-type, ModSecurity needs to know how to parse it and with which body processor. For example, an HTTP request with content-type “application/json” and a JSON body is parsed by ModSecurity using his JSON body processor. What it does is convert the JSON body to a list of values in the ARGS array.

Assuming that a web server with ModSecurity receives the following request:

ModSecurity JSON body processor creates the following variables:

 

What can go wrong with JSON parsers?

Thanks to the awesome research “An Exploration of JSON Interoperability Vulnerabilities” made by Jake Miller we learn a lot about how can possibly go wrong when multiple JSON parsers are in place. By web-fuzzing the JSON body processor of our solution Mithril WAAP, we found a critical payload not listed in Jake’s research. Our test consists of a JSON body with many nested arrays that produce a huge CPU consumption on Apache and Nginx with ModSecurity enabled, especially when they are used as a reverse proxy. For example, the following JSON request produces a nested array with a depth level of 10:

By incrementing the depth level of the nested array, we have seen an incremental response latency due to the ModSecurity JSON body processor. For example, the following python script sends a JSON body of ~500KB and receive a response from the target webserver after more than 90 seconds:

 

How we have patched it?

Waiting for the patch released by Trustwave on 24th November 2021 (v2.9.5 and v3.0.6), we patched the ModSecurity source code adding a new configuration directive “SecRequestBodyJsonDepthLimit” (name kept by Trustwave in both new ModSecurity releases) that checks how many nested arrays there are inside a JSON body. Our approach was to add this check before JSON body processor and this helped us a lot to protect immediately our customers from this DoS attack. The Trustwave solution uses YAJL to check the nested array depth. YAJL (Yet Another JSON Library) is a small event-driven (SAX-style) JSON parser written in ANSI C, and a small validating JSON generator.

 

How to check if my WAF is vulnerable and how to mitigate

If your application accepts application/json requests and you’re using ModSecurity 3.x through 3.0.5 or 2.8.0 through 2.9.4 so, you are vulnerable. Trustwave has published a useful list of scenarios and upgrade alternative that you can find here: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-dos-vulnerability-in-json-parsing-cve-2021-42717/.