4.2.2 update changed mod_security rule matching behaviour

J

jack

Member
#1
#1
Hi,

Last week we decided to update LS to 4.2.2, it has been out for a while so we assumed it would be a safe move. However things didn't run smoothly at all! We started getting a lot of false positives with the got_root rules leading to lots of 403 pages with some IP address blocks and a lot of support tickets to handle.

After a thorough check we saw that immediately after the upgrade a lot more web requests were being matched. At the time 3 rules were playing up and over the weekend 3 other rules have been whitelisted too. Oddly, those rules were previously regularly catching legitimate SQL injection attack requests and after the update we stopped seeing those being logged.

We haven't yet looked at the mod_security rule syntax, they seem like regexes, but this is a nice example of an odd match:

--340a1df9-H--
Message: [client 120.40.156.230] mod_security: Access denied with code 403, [Rule: 'REQUEST_URI' '!(?:/install/index\.php|/index\.php\?mode=install&sub=create_table$|^/admin/test/examples/txtsqladmin/index\.php|^/store/images/|^/wp-admin/admin\.php\?page=wpsc-settings)'] [ID "340157"] [Msg "Atomicorp.com UNSUPPORTED DELAYED Rules: Generic SQL inline command protection"] [severity "CRITICAL"] [MatchedString "lrefrkgcltzqgzetgbhyijchfcrgckvvuartrkkikbgfccayyixpcjkngtioaeupnbocomungnuisnozbdmpfxsmbaeewmmlyvhrpwqcbqcknggohsfnexlgfoyswsreelitnvmbggbbpjqalstddocetizxdmwdkrtghfamzllabpfcpprahsvleapokymmvtqkpqrotfpdjpzdyvvlpphmaifihcnsxqehyiayrubrpbiqiwrrpxswrqfbcnbgkqxoscyirguwhibefqwylupzkxbtcazjnjqivhonagztxojkvjsnynwkkfayxgrzlazzjmnchttebagjymyeaixsgvdrezsfmvjecaxogrnkjdvrrwpjvjbxqiwumttmuugchztshigooqszdyvvenpsgdodnmmlipdrgesdsjqrvqrxkdptqaxbpczsqtnewdloyialbnovmubvkhrhafzdbniufsmfactdjsvmlzbfafempqmelpfypwnaohmdqunjeiapwpzqirrwdqzrvfjysrkmmiijlhylkvbobcisdcevqjvlgllamjgwivknsvtctmxrqndiecrqrchukqnrgoowfgmeuspryqgmaftlvpyjbmrbknrrcmgfhrkrsctexwmsvjmsusaxoljrdafwnxerniouofivccyilckqtgnvafjimsmenxtmodfnaaliikacfjtszbkzavpnembswhvxsmioworlzedkmyrfvwzebkxtwpwfrocojcdiczkbrnsxilkdgjoapiqhmyxhiemlfxqdmumirwbjxikgtkkhiswqzprjcvisyrpmllpxtdgzwhjlckgthhypzaqsiswfxhgikrvrltxuhuxuimavsmyfbqlyunhjyuwznydmpyudvagfkfzcgandgtkyavclvmbypghtfeyijkbylgvenygrzwdvtwhsegorggtychjbtmffslccokakbiypibueotntealoejgegejjslvqvfjhorrqjopfdyenetlunjddnilcqdgzukggpsiikcpdyrijsycqqshkhkhuowppijipjpphpjpvzcvxmqxlocwphantatzcrsyiddnzxfqqqdupsjuzznptesscuqrbxgyxxipbpywxtwxwgjrpskvznzfbxaudwjzqg"]
--

Our servers run either CloudLinux 5 32bit or version 6 64bit.

The above example is from a CL 5 box.

We're running the got_root 2.5 rules.

Let us know if you'd like full logs so you can take a better look at them. Currently we're moving back to 4.2.1.

Best Regards,
Jack
 
J

jack

Member
#3
#3
Are you saying that there are several 4.2.2 versions sharing the same release number?

If that's so then it doesn't sound sensible at all. Shouldn't be hard to append a 4th number to reflect minor fixes.

Anyway, we installed "our version of the 4.2.2 version" on March 14 (5 days ago). Not going to push anything newer than 4.2.1 until we see a bump in the version number or get proper feedback.

All the best,
Jack
 
K

Karl

Active Member
#7
#7
4.2.3 is still broken, it is not processing rules correctly, for example:

Code: 
#SQL inline command attac?
SecRule REQUEST_URI|REQUEST_HEADERS|!REQUEST_HEADERS:Referer|!REQUEST_HEADERS:Cookie|!REQUEST_COOKIES|XML:/*|ARGS|!ARGS:/replaceAll/|!ARGS:/insertBefore/|!ARGS:/insertAfter/|!ARGS:/prependTo/|!ARGS:/insertstring/|!ARGS:pagetext|!ARGS:/appendTo/|!ARGS:json|!ARGS:data|!ARGS:areas|!ARGS:templatecode|!ARGS:contenido|!ARGS:/txt/|!ARGS:/text/|!ARGS:/teaser/|!ARGS:wpSummary|!ARGS:/narrative/|!ARGS:/installcode/|!ARGS:/php/|!ARGS:content|!ARGS:file_content|!ARGS:faqs_answer|!ARGS:/^para/|!ARGS:keywords|!ARGS:code|!ARGS:/sql/|!ARGS:data|!ARGS:/database/|!ARGS:/description/|!ARGS:alternate1|!ARGS:comment|!ARGS:body|!ARGS:fulldescr|!ARGS:article_content|!ARGS:query|!ARGS:/text/|!ARGS:txt|!ARGS:action|!ARGS:Db_submit|!ARGS:saved_data|!ARGS:form[pagina_text]|!ARGS:/message/|!ARGS:steps|!ARGS:fck_body|!ARGS:p_action|!ARGS:newcontent|!ARGS:/report/|!ARGS:/narrative/|!ARGS:/FCKeditor/  "(?:(\w+)(?:user|and)(\w+)char ?\([0-9]+\)|(?:execute|convert) ?\(|; ?\bdelete\b.{1,100}?; ?(?:insert|declare @|varchar) ?|and .{1,100} \(select |(?:drop|create)(\w+)table |(?:declare|convert) .{1,100} varchar\(|null ?, ?null ?, ?(accesslevel|user_?name) ?,|concat\(|union select |union all select|xecresultset|' ?; ?declare\b ?@|; ?set @|select (?:load_file|char ?\()|(?:insert|remark)test;)" \
	"phase:2,deny,status:403,capture,id:340157,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,rev:36,severity:2,msg:'Atomicorp.com UNSUPPORTED DELAYED Rules: Generic SQL inline command protection',chain,logdata:'%{TX.0}'"
SecRule REQUEST_URI "!(?:/install/index\.php|/index\.php\?mode=install&sub=create_table$|^/admin/test/examples/txtsqladmin/index\.php|^/store/images/|^/([a-z]+/)?wp-admin/(?:admin|options-general)\.php\?page=wpsc-settings)"  "t:none,t:lowercase"
That rule should ignore what is in cookies - but it doesn't, it matches against cookies in 2.4.3 - in 2.4.1 the rule functions correctly, it ignores cookies.
 
You must log in or register to reply here.
Top