workaround for modsecurity false positive?

Question

I was pasting "drwxr-xr-x. 2 root root 6 Sep 24 04:35 images" into a dokuwiki page That triggered modsecurity and I got a HTTP error. How can this rule be modified to avoid this kind of false positive?

It happened on Dreamhost and support was telling me this rule has been successful at thwarting attacks. What kind of attack is it trying to prevent? If someone wants to view file permissions the malicious code can simply reformat the response (e.g showing 774 instead) to bypass the regex matching instead of showing the raw output.

ModSecurity: Access denied with code 418 (phase 4). Pattern match "(?:[^<]*?(?:\b(?:(?:c(?:ehennemden|gi-telnet)|gamma web shell)\b|imhabirligi phpftp)|(?:r(?:emote explorer|57shell)|aventis klasvayv|zehir)\b|\.::(?:news remote php shell injection::\.| rhtools\b)|ph(?:p(?:(?: commander|-terminal)\b|remoteview)| ..." at RESPONSE_BODY. [file "/dh/apache2/template/etc/mod_sec2/modsecurity_crs_45_trojans.conf"] [line "34"] [id "950922"] [msg "Backdoor access"] [severity "CRITICAL"] [tag "MALICIOUS_SOFTWARE/TROJAN"]

Answer 1

The full rule is this:

SecRule RESPONSE_BODY "(?:<title>[^<]*?(?:\b(?:(?:c(?:ehennemden|gi-telnet)|gamma web shell)\b|imhabirligi phpftp)|(?:r(?:emote explorer|57shell)|aventis klasvayv|zehir)\b|\.::(?:news remote php shell injection::\.| rhtools\b)|ph(?:p(?:(?: commander|-terminal)\b|remoteview)|vayv)|myshell)|\b(?:(?:(?:microsoft windows\b.{0,10}?\bversion\b.{0,20}?\(c\) copyright 1985-.{0,10}?\bmicrosoft corp|ntdaddy v1\.9 - obzerve \| fux0r inc)\.|(?:www\.sanalteror\.org - indexer and read|haxplor)er|php(?:konsole| shell)|c99shell)\b|aventgrup\.<br>|drwxr))" \
    "phase:4,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'8',accuracy:'8',t:none,ctl:auditLogParts=+E,block,msg:'Backdoor access',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',capture,id:'950922',tag:'OWASP_CRS/MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5.1.1',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.trojan_score=+1,setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/MALICIOUS_SOFTWARE/TROJAN-%{matched_var_name}=%{matched_var}"

This does match above because of the last test: drwxr. I'm not sure why this was added to this rule as there's no explanation in the comments, and this was in the 2.6 version originally committed to GitHub.

Anyway you've several options:

You could edit the rule to remove that last check. This is not recommended, since any future upgrade of your rules will reinstate it.

You could just turn off that rule by adding the following to your config (after you have loaded the rule from /dh/apache2/template/etc/mod_sec2/modsecurity_crs_45_trojans.conf)

 SecRuleRemoveById 950922

You could also turn off response body parsing:

SecResponseBodyAccess Off

Scanning response bodies can affect performance so you should consider this anyway. Requests are typically small (e.g. GET /index.html) but responses will contain a lot more data.

In theory you should know what is in your responses (providing you have protection against SQL injections and XSS and the like), so it might not make sense to scan outbound responses.

The counter argument is that response body checking is useful for preventing information leakage (e.g. a SQL injection attack which is used to leak information from your database). Then again if you allow a SQL injection you are in deep trouble anyway even without leaking information.

Personally I don't find scanning response bodies that useful except in specific use cases so have them off by default and turn them on for certain URLs.