False Positives with mod_security

by J. Edward Durrett

Deploying a Web Application Firewall such as mod_security for Apache is a task that takes a small amount of
technical skill and quite a bit of patience. In fact, installing can be done in less than 5 minutes. Although some
planning on the initial rule set and a definition of goals is needed, the majority of time is spent watching and
adjusting. The following is an example of a legitimate request blocked, aka false positive, by the WAF and how to
correct it.

In this scenario, the web server is running an API to connect to Twilio’s programmable SMS. When a text
message is sent to a phone number that is associated with Twilio, the Twilio servers send a POST request to the
web server with authentication and the body of the text message. With mod_security running, this may cause the
following error is written to the error log if there are offending characters in the POST request:

[Sat Apr 08 15:10:29.847780 2017] [:error] [pid 73134] [client  
■■.■■■.■■■.■■:57526] [client ■■.■■■.■■.■■] ModSecurity:
Warning. Pattern match
..." at ARGS:Body. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "185"] [id
"932110"] [rev "4"] [msg "Remote Command Execution: Windows Command Injection"] [data "Matched Data:
\\x0a\\x0a■■■■■■■■■■■■■■■■■/■■■■ found within
[severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] [tag
"language-shell"] [tag "platform-windows"] [tag "attack-rce"] [tag "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION"] [tag
"WASCTC/WASC-31"] [tag "OWASP_TOP_10/A1"] [tag "PCI/6.5.2"] [hostname "www.jedwarddurrett.com"] [uri
"/■■■/■■■■■■■■■"] [unique_id "WOj9ZcCoAAgAAR2uOqEAAAAA"]

[Sat Apr 08 15:10:29.863679 2017] [:error] [pid 73134] [client ■■.■■■.■■■.■■:57526]
[client ■■.■■■.■■■.■■] ModSecurity: Access denied with code 403 (phase 2). Operator
GE matched 5 at TX:anomaly_score. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "57"] [id
"949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"]
[tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "www.jedwarddurrett.com"] [uri
"/■■■/■■■■■■■■■■"] [unique_id "WOj9ZcCoAAgAAR2uOqEAAAAA"]

I already know that this is a legitimate request from a trusted source so mod_security needs to be tweaked. All
the information needed to fix the false positive is in the output of the error log. The file
REQUEST-932-APPLICATION-ATTACK-RCE.conf on line 185 contains the rule that blocked the request. Looking at the
comments above the rule the answer is plain as day:

# [ Windows command injection ] 
# This rule detects Windows shell command injections.
# If you are not running Windows, it is safe to disable this rule.

Well, since I am not running Windows, disabling the rule solves the false positive. If, however, I needed to solve
the problem without disabling the rule, there are a couple of options. One is to recompile the regular expression
to allow the offending character as documented in the comments section in REQUEST-932-APPLICATION-ATTACK-RCE.conf:

# To rebuild the word list regexp: 
# cd util/regexp-assemble
# cat regexp-932110.txt | ./regexp-cmdline.py windows | ./regexp-assemble.pl

There should be a step in the middle, and that is to exit the file regexp-932110.tx before rebuilding it. Great
care should be taken that by disabling the match for the special character that came in the SMS message, a
possible attack method is actually being enabled.

On a complex site with many web applications, adjusting mod_security to both provide a high level of assurance and
keeping all the services accessible is an exercise in methodological patience.

Copyright (c) 2019, Jason Edward Durrett - All content on this site, unless otherwise noted, is subject to this license.

Please contact me if any errors, such as erroneous / misleading content or missing / incomplete attribution, are found.