Thread: [mod-security-users] False positive "un"-whitelistable
Brought to you by:
victorhora,
zimmerletw
From: David R <re...@li...> - 2012-07-30 13:49:19
|
Hello, For a starnge reason i cannot manage to whitelist a specific argument... Below all rules i tried followed the modsec_audit.log extracton. Any help would be really appreciated === <Location /url/login.php> SecRuleUpdateTargetById 981318 "!ARGS:email" </Location> === <LocationMatch /url/login.php> SecRuleUpdateTargetById 981318 "!ARGS:email" </LocationMatch> === SecRule REQUEST_FILENAME "@streq /url/login.php" "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=981242:!ARGS:email" === SecRule REQUEST_URI ".*/url/login.php.*" "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=981242:!ARGS:email" === even this doesn't work: SecRuleUpdateTargetById 981318 "!ARGS:email" === also tried with phase=2 and both phase=1 then phase=2 POST /url/login.php HTTP/1.1 Host: obfuscated.com Connection: keep-alive Content-Length: 130 Cache-Control: max-age=0 Origin: http://obfuscated.com User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like Gecko) Ubuntu/10.04 Chromium/17.0.963.79 Chrome/17.0.963.79 Safari/535.11 Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://obfuscated.com/url/login.php Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: c_language=fr; PHPSESSID=ae90732196ee14953a22ddcbadfeb42f; RT=.2; obfuscated=.web4; obfuscated-comp=0; ysm_bbk1EIOR5LTD5HQOR6UROJ48THLME8=14424707; testing_cookie; __utma=56222831.1398252698.1336980991.1343640089.1343650146.44; __utmb=56222831.8.10.1343650146; __utmc=56222831; __utmz=56222831.1336980991.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) --2fdeee79-C-- option=m&state=200&agefrom=18&ageto=99&sorttype=0&ordertype=0&order=1&email=0%22 &srname=Naonkatite_7&emailaddress=&filtersubmit=GO --2fdeee79-F-- HTTP/1.1 302 Found Location: http://obfuscated.com/page_notfound.html Content-Length: 313 Connection: close Content-Type: text/html; charset=iso-8859-1 --2fdeee79-H-- Message: [file "/etc/httpd/modsecurity.d/modsecurity_crs_41_sql_injection_attacks.conf"] [line "68"] [id "981318"] [rev "2.2.4"] [msg "SQL Injection Attack: Common Injection Testing Detected"] [data "\x22"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] Access denied with redirection to http://obfuscated.com/page_notfound.html using status 302 (phase 2). Pattern match "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+| [\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+$)" at ARGS:email. Action: Intercepted (phase 2) Apache-Handler: proxy-server Stopwatch: 1343655283114172 5042 (- - -) Stopwatch2: 1343655283114172 5042; combined=4123, p1=411, p2=3669, p3=0, p4=0, p5=42, sr=0, sw=1, l=0, gc=0 WAF: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/); 201001071602; 201001071602. Server: Apache/2.2.15 (CentOS |
From: Breno S. <bre...@gm...> - 2012-07-30 14:40:34
|
Hey David, I just insert SecUpdateTargetById after the rule 981318: SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(^[\"'`´’‘;]+|[\"'`´’‘;]+$)" "phase:2,rev:'2.2.3',capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: Common Injection Testing Detected',id:'981318',logdata:'%{TX.0}',severity:'2',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{ rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}" SecRuleUpdateTargetById 981318 "!ARGS:email" And works fine: [30/Jul/2012:10:15:30 --0400] [ 172.16.51.132/sid#22379ce0][rid#22386d40][/][4] Recipe: Invoking rule 2232f6f0; [file "/etc/apache2/modsecurity/modsecurity_crs_15_customrules.conf"] [line "446"] [id "981318"] [rev "2.2.3"]. [30/Jul/2012:10:15:30 --0400] [ 172.16.51.132/sid#22379ce0][rid#22386d40][/][5] Rule 2232f6f0: SecRule "REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*|!ARGS:email" "@rx (^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+$)" "phase:2,log,auditlog,rev:2.2.3,capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: Common Injection Testing Detected',id:981318,logdata:%{TX.0},severity:2,tag:WEB_ATTACK/SQL_INJECTION,tag:WASCTC/WASC-19,tag:OWASP_TOP_10/A1,tag:OWASP_AppSensor/CIE1,tag:PCI/6.5.2,setvar:tx.msg=%{rule.msg},setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{ rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}" Please make sure: - You are loading it after the SecRule - Make sure there is no duplicated IDs If you want to try (i will still anounce it)... get 2.6.7 tarball in sourceforge and use ctl:ruleRemoveTargetById:981318;ARGS:email (no need !) Thanks Breno On Mon, Jul 30, 2012 at 8:48 AM, David R <re...@li...> wrote: > Hello, > For a starnge reason i cannot manage to whitelist a specific argument... > Below all rules i tried followed the modsec_audit.log extracton. > > Any help would be really appreciated > > === > <Location /url/login.php> > SecRuleUpdateTargetById 981318 "!ARGS:email" > </Location> > === > <LocationMatch /url/login.php> > SecRuleUpdateTargetById 981318 "!ARGS:email" > </LocationMatch> > === > SecRule REQUEST_FILENAME "@streq /url/login.php" > "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=981242:!ARGS:email" > === > SecRule REQUEST_URI ".*/url/login.php.*" > "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=981242:!ARGS:email" > === > even this doesn't work: > SecRuleUpdateTargetById 981318 "!ARGS:email" > === > > also tried with phase=2 and both phase=1 then phase=2 > > POST /url/login.php HTTP/1.1 > Host: obfuscated.com > Connection: keep-alive > Content-Length: 130 > Cache-Control: max-age=0 > Origin: http://obfuscated.com > User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like > Gecko) > Ubuntu/10.04 Chromium/17.0.963.79 Chrome/17.0.963.79 Safari/535.11 > Content-Type: application/x-www-form-urlencoded > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Referer: http://obfuscated.com/url/login.php > Accept-Encoding: gzip,deflate,sdch > Accept-Language: en-US,en;q=0.8 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 > Cookie: c_language=fr; PHPSESSID=ae90732196ee14953a22ddcbadfeb42f; RT=.2; > obfuscated=.web4; obfuscated-comp=0; > ysm_bbk1EIOR5LTD5HQOR6UROJ48THLME8=14424707; testing_cookie; > __utma=56222831.1398252698.1336980991.1343640089.1343650146.44; > __utmb=56222831.8.10.1343650146; __utmc=56222831; > > __utmz=56222831.1336980991.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) > > --2fdeee79-C-- > > option=m&state=200&agefrom=18&ageto=99&sorttype=0&ordertype=0&order=1&email=0%22 > &srname=Naonkatite_7&emailaddress=&filtersubmit=GO > --2fdeee79-F-- > HTTP/1.1 302 Found > Location: http://obfuscated.com/page_notfound.html > Content-Length: 313 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > --2fdeee79-H-- > Message: [file > "/etc/httpd/modsecurity.d/modsecurity_crs_41_sql_injection_attacks.conf"] > [line > "68"] [id "981318"] [rev "2.2.4"] [msg "SQL Injection Attack: Common > Injection > Testing Detected"] [data "\x22"] [severity "CRITICAL"] [tag > "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] > [tag > "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] Access denied with redirection to > http://obfuscated.com/page_notfound.html using status 302 (phase 2). > Pattern > match "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+| > [\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+$)" at ARGS:email. > Action: Intercepted (phase 2) > Apache-Handler: proxy-server > Stopwatch: 1343655283114172 5042 (- - -) > Stopwatch2: 1343655283114172 5042; combined=4123, p1=411, p2=3669, p3=0, > p4=0, > p5=42, sr=0, sw=1, l=0, gc=0 > WAF: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/); > 201001071602; > 201001071602. > Server: Apache/2.2.15 (CentOS > > > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
From: David R <re...@li...> - 2012-07-30 14:56:31
|
Dear Breno, At first many thanks for this fast reply! I can confirm this is working but this doe snot explain why i can't include a REQUEST_URI to be more "precise". Do you know any workaround that should work to be able to set also the REQUEST_URI or REQUEST_FILENAME with that rule ? Please let me know. Kind regards, David |
From: Breno S. <bre...@gm...> - 2012-07-30 15:06:12
|
Hello David, Did you try ? SecRuleUpdateTargetById 981318 "!ARGS:email,REQUEST_URI" REQUEST_FILENAME already exists in the rule, so it will be no included. Thanks Breno On Mon, Jul 30, 2012 at 9:56 AM, David R <re...@li...> wrote: > Dear Breno, > > At first many thanks for this fast reply! > > I can confirm this is working but this doe snot explain why i can't > include a > REQUEST_URI to be more "precise". > > Do you know any workaround that should work to be able to set also the > REQUEST_URI or REQUEST_FILENAME with that rule ? > > Please let me know. > Kind regards, > > David > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
From: David R <re...@li...> - 2012-07-30 15:58:11
|
You definitely ROCKS :D I pu that in my 999 exception file: SecRuleUpdateTargetById 981318 "!ARGS:email,REQUEST_URI:/url/login.php" And WAHOUO IT WORKED !!! I just don't understand why these syntaxes are not listed anywhere on the Internet !!!! And if i wanted to be a bit more complicated is it possible in any maneer to include an REQUEST_HEADERS:Host condition (matching a specific VHOST) maybe with a chain or something like that ? I tried this: SecRuleUpdateTargetById 981318 "!ARGS:email,REQUEST_URI:/url/login.php,REQUEST_HEADERS:Host\ \"precise\.obfuscated.com\",log" But the vhost wasn t considered in the rule and the log directive not considered too And do you know any possibility to fully whitelist a parameter (like a send message box) ? I think that your replys will greatly help people searching on Google. Many thanks to you for your kind help. David |
From: Breno S. <bre...@gm...> - 2012-07-30 16:11:56
|
Cool, Do you want to ignore REQUEST_HEADERS:Host in 981318 if it contains the word "obfuscated" ? You can do this using the new 2.6.7: SecRule REQUEST_HEADERS:Host "obfuscated" "id:12345,ctl:ruleRemoveTargetById=981318;REQUEST_HEADERS:Host" ps: Don't need " ! " in ruleRemoveTargetById. Thanks Breno On Mon, Jul 30, 2012 at 10:57 AM, David R <re...@li...> wrote: > You definitely ROCKS :D > I pu that in my 999 exception file: > > SecRuleUpdateTargetById 981318 "!ARGS:email,REQUEST_URI:/url/login.php" > > And WAHOUO IT WORKED !!! > I just don't understand why these syntaxes are not listed anywhere on the > Internet !!!! > > And if i wanted to be a bit more complicated is it possible in any maneer > to > include an REQUEST_HEADERS:Host condition (matching a specific VHOST) > maybe with > a chain or something like that ? > > I tried this: > SecRuleUpdateTargetById 981318 > "!ARGS:email,REQUEST_URI:/url/login.php,REQUEST_HEADERS:Host\ > \"precise\.obfuscated.com\",log" > But the vhost wasn t considered in the rule and the log directive not > considered > too > > > > And do you know any possibility to fully whitelist a parameter (like a send > message box) ? > > > I think that your replys will greatly help people searching on Google. > > Many thanks to you for your kind help. > > David > > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
From: David R <re...@li...> - 2012-07-31 06:39:13
|
Hi, Thank you for this update, but in your previous syntax you didn t consider the REQUEST_URI, is there a way to do a precise whitelist matching: REQUEST_HEADER:Host REQUEST_URI rule_id Kind regards, |