Re: [mod-security-users] core rule set vs gotroot ruleset

[Ryan B. <Rya...@br...>]

-----Original Message-----
From: Michael Shinn [mailto:mi...@go...]
Sent: Tuesday, March 17, 2009 1:55 PM
To: Brian Rectanus
Cc: Mod Security
Subject: Re: [mod-security-users] core rule set vs gotroot ruleset



On Tue, 2009-03-17 at 10:10 -0700, Brian Rectanus wrote:

> Actually, looking at 20_asl_useragents.conf, I see you are using:

>

>

> SecDefaultAction

> "log,deny,auditlog,phase:2,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace"

>

> Then you follow up with many regex patterns that use capital letters.

> These will never match with the t:lowercase you used above.



FYI, update just released for these issues and thanks again for pointing

them out Brian.



[Ryan Barnett] Well, as long as we are on "false positive" issue thread...



Here are a few more items -



1.  Incorrect PCRE flag usage - there are some rules that are obviously converted from Snort rules as the RegEx payloads include the Snort "pcre:/.../Ui" ignore case/Urldecode flags.  For example in this file - http://downloads.prometheus-group.com/delayed/rules/modsec/99_asl_jitp.conf - is the following rule -



# Rule 310277: vBulletin Remote Command Execution Attempt

SecRule REQUEST_URI "/forumdisplay\.php?[^\r\n]*comma=[^\r\n\x26]*system\x28.*\x29/Ui" \

        "id:310277,rev:1,severity:1,msg:'JITP: vBulletin forumdisplay.php local command execution attempt'"



The "/Ui" at the end of the RegEx string will never match.



2.  Including the "="  in the arg name - in the same JITP file, there are some rules that include the "=" in the argument name -



# Rule 310019: HP-Nuke <=7.8 SQL injection exploit

SecRule REQUEST_URI "/modules\.php" chain

SecRule ARGS:name= "\'.*UNION.*SELECT.*FROM.*users.*WHERE.*user_id=.*AND"



The 2nd part of this chained rule is supposed to be looking at "ARGS:name" and not "ARGS:name=" as the = is the separator between the arg name and arg payload.



3.  Whitelist (IP vs. Domain Name) - make sure that anytime you are inspecting the REMOTE_ADDR variable that the payloads are actually IP addresses.  One example was the whitelist.txt file that listed "www.google.com" which wouldn't match.



4.  Performance (Exceptions) - I see that a number of the rules are attempting to avoid false positives by specifying variable exclusions on the first rule in a chained ruleset -



# Rule 340006: generic recursion signatures

SecRule REQUEST_URI "!(alt_mod_frameset.php|checkout_shipping.php|^/components/com_zoom/etc/|/admin\.swf\?nick=|/editor/filemanager/browser/default/browser\.html\?(Type=Image&)?Connector=\.\./\.\./connectors|phpthumb/phpthumb\.php\?src=\.\./\.\./uploads)" \

      "t:normalisePath,id:340006,rev:27,severity:2,msg:'Generic Path Recursion denied in URI/ARGS', chain"

SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|!ARGS:css_data|!ARGS:/txt/|!ARGS:/text/|!ARGS:body|!ARGS:pagecontent|!ARGS:wysiwyg_input||!ARGS:backPath|!ARGS:webpage[content]|!ARGS:article[content]|!ARGS:filecontent|!ARGS:/text/|!ARGS:/message/|!ARGS:/^fck_/|!ARGS:htmlSource|!ARGS:path_to_lzx|!ARGS:/content/ "(?:\.\./\.\./|\.\|\./\.\|\./\.\|)"



Obviously, there are some false positives that you have identified in the REQUEST_URI and ARGS so you are excluding them up front.  Technically, this works, however you are essentially verify BOTH rules for every request.  In order to get better performance, you should specify the most "anomalous" part for the chained rule FIRST and then use the other parts of the chained rule to do exclusions.  This way, you will only ever process the exclusions if the negative security rule matched in the first place.



-Ryan