0

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"]

sdaffa23fdsf
  • 215
  • 1
  • 2
  • 8
  • t would help to see exactly what triggered it. – user9517 Nov 13 '15 at 08:14
  • just plain text like "drwxrwxr-x 2 root root 4096 Nov 12 12:18 logs" into the text of the wiki page – sdaffa23fdsf Nov 13 '15 at 08:27
  • That text will not trigger that rule. Are you quite sure you haven't been compromised? – Michael Hampton Nov 13 '15 at 08:29
  • "drwxr-xr-x. 2 root root 6 Sep 24 04:35 images" is the exact text in the wiki page that triggered that rule – sdaffa23fdsf Nov 13 '15 at 14:21
  • 1
    You're looking at the wrong end. Phase 4/ Response Body is analysis of the text of the response to the client, not input from the client. You will need to look at what you are trying to send back. – user9517 Nov 13 '15 at 14:45
  • When I submit the page with text "drwxr-xr-x. 2 root root 6 Sep 24 04:35 images" it comes back in the response because I will be viewing the page I just edited when I hit submit (this happens when I edit a dokuwiki page). I can verify this is the exact string that triggered modsecurity. – sdaffa23fdsf Nov 13 '15 at 22:52

1 Answers1

2

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.

Barry Pollard
  • 4,461
  • 14
  • 26
  • In this case, the last item "drwxr" is looking for the output of ls -l within the traffic. I ran into this trying to post a blog entry with command-line examples. If you're in a similar situation, you can insert a wbr html element, or if that doesn't work, insert the unicode 0-width space character in every example of "drwxr" in your response. – Keith Twombley Dec 02 '15 at 23:32