mod_security False Positives

I’ll go through a false positive example I found on my blog. False positives are inevitable, so it’s not a bad idea to run mod_security for a few weeks on detect only.

Here’s the url that was raising the alarm. The trigger was in the url.

http://chesterton.id.au/blog/2007/11/20/blue-tongue-harmonica-talk-cd/

Here’s what modsec_audit.log looked like

--f8a03521-A--
[21/Mar/2011:07:54:47 +1100] TYZpl0LcAZkAAHCLBPIAAAAA ::ffff:124.169.31.22 34169 127.0.0.1 81
--f8a03521-B--
GET /blog/2007/11/20/blue-tongue-harmonica-talk-cd/ HTTP/1.0
Host: chesterton.id.au
X-Real-IP: ::ffff:124.169.31.22
X-Forwarded-For: ::ffff:124.169.31.22
Connection: close
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.26 (KHTML, like Gecko) Ubuntu/10.10 Chromium/12.0.709.0 Chrome/12.0.709.0 Safari/534.26
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

--f8a03521-F--
HTTP/1.1 403 Forbidden
Content-Length: 370
Connection: close
Content-Type: text/html; charset=iso-8859-1

--f8a03521-H--
Message: Access denied with code 403 (phase 2). Pattern match "bcdbW*?[/]" at REQUEST_FILENAME. [file "/etc/apache2/modsecurity_crs/base_rules/modsecurity_crs_40_generic_attacks.conf"] [line "396"] [id "958821"] [rev "2.1.2"] [msg "System Command Injection"] [data "cd/"] [severity "CRITICAL"] [tag "WEB_ATTACK/COMMAND_INJECTION"] [tag "WASCTC/WASC-31"] [tag "OWASP_TOP_10/A1"] [tag "PCI/6.5.2"]
Action: Intercepted (phase 2)
Stopwatch: 1300654487217847 3874 (2435 3436 -)
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/); core ruleset/2.1.2.
Server: Apache/2.2.14 (Ubuntu) PHP/5.3.2-1ubuntu4.7 with Suhosin-Patch

--f8a03521-Z--

Section B –f8a03521-B– contains the request headers, and you can see the GET is /blog/2007/11/20/blue-tongue-harmonica-talk-cd/.

Section H is the audit log, why it was blocked in this case.
[msg “System Command Injection”] [data “cd/”] so it didn’t like cd/, I’m not sure that cd/ (without a space between the cd and the directory) would do much on a unix system, but perhaps it does on windows, where apache also runs.

It also tells you the pattern that matched, the file where the rule is located and the rule id.
Pattern match “bcdbW*?[/]” at REQUEST_FILENAME. [file “/etc/apache2/modsecurity_crs/base_rules/modsecurity_crs_40_generic_attacks.conf”] [line “396”] [id “958821”]

What we can do, is when REQUEST_FILENAME = /blog/2007/11/20/blue-tongue-harmonica-talk-cd/ remove rule id 958821.

SecRule REQUEST_FILENAME "^/blog/2007/11/20/blue-tongue-harmonica-talk-cd/(index.php)?$" "nolog,pass,ctl:RuleRemoveById=958821"

Add this rule to your local rules, the reason we don’t modify the base_rules is they get overwritten when there’s an update to the rules.

“pass” above means if the rule matches, keep processing other rules, so it will still catch xss for example:

http://chesterton.id.au/blog/2007/11/20/blue-tongue-harmonica-talk-cd/?a=%3Cscript%3Ealert(1)%3C/script%3E

I’d like to come back to this later and lock it down a little.