OK. I haven’t written long time on blog. Today I want to show you what sometimes
yum can do without your knowledge. Few days ago I was upgrading one of system using yum.
Everything looked fine. I was happy that sometimes yum is useful. After work I went sleep
and next day I received messages that smth is fu** up with www…


… yep and the real history is starting now 🙂 After update nobody can log into wordpress. When you go to site you saw only text and all design was not loaded. In logs I saw message 403 – Access Denied. Hm… but yesterday everything was working good. WTF? Someone compromised my box? Change the permission? Hm… let’s look… Hm… permission is good so why I have 403 message? Let’s look for rootkits 🙂 After few hours I was almost  sure that box was clean!
Let’s check another test. I was creating directory ‘wp-content’ on random site and put some random file. When I send request for this file i received  403 message once again. When I moved file to upper directory – everything worked fine 🙂 Strange 🙂 Let’s look for logs once again… What I saw? Look:

–c28ca12d-B–
GET /wp-content/themes/gods-and-monsters/style.css HTTP/1.1


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

–c28ca12d-H–
Message: Pattern match “([^*:\s\w,.\/?+-]\s*)?(?<![a-z]\s)(?<![a-z_@>\|])(\s*return\s*)?(?:globalstorage|sessionstorage|postmessage|callee|constructor|content|domain|prototype|try|catch|top|call|apply|url|function|object|array|string|math|if|elseif|case|switch|regex|boolean|l …” at REQUEST_URI_RAW. [file “/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_41_phpids_filters.conf”] [line “67”] [id “phpids-20”] [msg “Detects JavaScript language constructs”] [data “content/”] [severity “CRITICAL”] [tag “WEB_ATTACK”]

WTF? “Detects JavaScript language constructs” ? “CRITICAL” ? LOL Let’s look for this strange filter:

-rw-r–r– 1 root root  xxK 11-29 xx:xx modsecurity_crs_41_phpids_filters.conf
-rw-r–r– 1 root root  xxK 11-29 xx:xx modsecurity_crs_40_generic_attacks.conf

Hm this files was modified when i was upgrading system 🙂 Line 67 looks like:

SecRule REQUEST_BODY|REQUEST_URI_RAW|XML:/* “([^*:\s\w,.\/?+-]\s*)?(?<![a-z]\s)(?<![a-z_@>\|])(\s*return\s*)?(?:globalstorage|sessionstorage|postmessage|cal
lee|constructor|content|domain|prototype|try|catch|top|call|apply|url|function|object|array|string|math|if|elseif|case|switch|regex|boolean|location|settimeo
ut|setinterval|void|setexpression|namespace|while)(?(1)[^\w%\”]|(?:\s*[^@\s\w%\”,.+\-]))” “phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replace
Comments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,nolog,auditlog,msg:’Detects JavaScript language constructs’,id:’phpids-20′,tag:’WEB_ATTA
CK’,logdata:’%{TX.0}’,severity:’2′,setvar:’tx.msg=%{rule.msg}’,setvar:tx.anomaly_score=+20,setvar:tx.%{rule.id}-WEB_ATTACK-%{matched_var_name}=%{matched_var}

heh 🙂 So everything which was in wp-content was blocked by mod_security 🙂 I removed this line and some other strange (bad access wasn’t causes  only by this line) and everything back to normal 🙂

Conclusion:
*) I always have been compiling by hand and modifying  by hand everything so I always know what I do. When you are using automatic tools you can be surprised  🙂
*) I didn’t believe that mod_security could causes this problem so I ignored this logs on first reading – and it causes longer time to discover real  problem 🙂
*) Automatic tool = faster but you should always check everything before you “Accept” his job 🙂

Best regards,
Adam Zabrocki

Comments

  1. Borys Łącki on 12.03.2009

    Automatic tool = faster but you should always check everything before you “Accept” his job – my favourite :]

  2. Christian Rodriguez on 01.13.2010

    Hey there – was setting up wordpress tonight and ran into this same problem. Had me stumped for a few hours before I figured out it was mod_security, and before I specifically tracked it down to this line.

    I didn’t remove the entire line; instead I just removed |content| and so far everything is working. I’m definitely suspicious, though, and will keep an eye on this rule and disable it if it becomes a problem.

  3. admin on 01.13.2010

    Hi Christian

    If you won’t have any problems with your changing mod_security configuration, give me this information 🙂 I will check it too…

    Best regards,
    Adam Zabrocki

Leave a Reply




CAPTCHA * Time limit is exhausted. Please reload the CAPTCHA.