Hey Jamie, I agree with your assessment and the need to strengthen the coverage. We have a script that auto-converts the ET Snort web signatures from here - http://rules.emergingthreats.net/open/snort-2.8.4/rules/ - into the SLR ModSecurity rules.
Reference blog post - http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-i ntegrating-ids-signatures.html The issue here is that there was not a consistent format used by ET Snort sig writers. For good virtual patches, we need mainly need: 1) URI, 2) Param name - injection point and 3) Attack Category. With this data, we can auto-create a pretty good rule. Let's look at one example. Here is an SQL vuln - #by tinytwitty # alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB_SPECIFIC_APPS GaziYapBoz Game Portal SQL Injection Attempt -- kategori.asp kategori UPDATE"; flow:established,to_server; uricontent:"/kategori.asp?"; nocase; uricontent:"kategori="; nocase; uricontent:"UPDATE"; nocase; pcre:"/UPDATE.+SET/Ui"; reference:cve,CVE-2007-1410; reference:url,www.milw0rm.com/exploits/3437; reference:url,doc.emergingthreats.net/2004402; classtype:web-application-attack; sid:2004402; rev:5;) We got the needed info: 1) uricontent:"kategori.asp?" 2) uricontent:"kategori=" 3) SQL Injection With this info, our scripts auto-created this rule - # (2004402) SpiderLabs Research (SLR) Public Vulns: ET WEB_SPECIFIC_APPS GaziYapBoz Game Portal SQL Injection Attempt -- kategori.asp kategori UPDATE SecRule REQUEST_LINE "@contains /kategori.asp" "chain,phase:2,block,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalisePa thWin,capture,nolog,auditlog,logdata:'%{TX.0}',severity:'2',id:2004402,rev: 5,msg:'SLR: ET WEB_SPECIFIC_APPS GaziYapBoz Game Portal SQL Injection Attempt -- kategori.asp kategori UPDATE',tag:'web-application-attack',tag:'url,www.milw0rm.com/exploits/3437 '" SecRule &TX:'/SQL_INJECTION.*ARGS:kategori/' "@gt 0" "ctl:auditLogParts=+E,setvar:'tx.msg=ET WEB_SPECIFIC_APPS GaziYapBoz Game Portal SQL Injection Attempt -- kategori.asp kategori UPDATE',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{ rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{matched_var}'" The issue with the particular Snort sig that you highlighted is that it doesn't clearly indicate the injection point/param by using - uricontent:"param=" syntax. #Submitted 2006-06-29 by Frank Knobbe # alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB_SPECIFIC_APPS GeekLog Remote File Include Vulnerability"; flow:established,to_server; uricontent:".php?"; nocase; uricontent:"_CONF"; nocase; pcre:"/_CONF\[.*\]=(http|ftps?|php)\:\//Ui"; reference:url,securitydot.net/xpl/exploits/vulnerabilities/articles/1122/ex ploit.html; reference:url,doc.emergingthreats.net/2002996; classtype:web-application-attack; sid:2002996; rev:6;) When we don't get this clean param data, we revert to using the data provided by the original Snort rule writer. So, your concerns about the regex are valid but we currently can't do much about it... I will try and look at updating our script to better handle these issues. -- Ryan Barnett Trustwave SpiderLabs ModSecurity Project Leader OWASP ModSecurity CRS Project Leader On 10/19/12 6:43 AM, "Jamie Riden" <ja...@honeynet.org> wrote: >Hi all, > >I found one rule which doesn't check for =https:// RFI attacks: > >./slr_rules/modsecurity_crs_46_slr_et_rfi_attacks.conf > >SecRule QUERY_STRING|REQUEST_BODY >"(?i:_CONF\[.*\]=(http|ftps?|php)\:\/)" >"ctl:auditLogParts=+E,setvar:'tx.msg=ET WEB_SPECIFIC_APPS GeekLog >Remote File Include >Vulnerability',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setva >r:'tx.%{rule.id}-WEB_ATTACK/RFI-%{matched_var_name}=%{matched_var}'" > >This should be =(https?|ftps?|php) - same for all PHP remote file >includes, they're technically possible over any of those protocols. > >( For that matter, data:// or zlib:// should be possible too - see >e.g. http://www.php.net/manual/en/wrappers.data.php , and >http://www.php.net/manual/en/wrappers.php > >I have mentioned this to ET's Matt Jonkman in the past, but I gather >he was worried about the performance hit from checking >(=data|https?|ftps?|zlib| etc etc) for >all PHP RFI sigs in Emerging Threats. mod_security may not be so >sensitive to the extra pattern matches. Just something to think about >- I can try for a proof of concept if anyone's interested?) > >cheers, > Jamie >-- >Jamie Riden / ja...@honeynet.org / jamie.ri...@gmail.com >http://uk.linkedin.com/in/jamieriden > > >-- >Jamie Riden / ja...@honeynet.org / jamie.ri...@gmail.com >http://uk.linkedin.com/in/jamieriden >Jamie Riden / ja...@honeynet.org / jamie.ri...@gmail.com >http://uk.linkedin.com/in/jamieriden >Jamie Riden / ja...@honeynet.org / jamie.ri...@gmail.com >http://uk.linkedin.com/in/jamieriden >_______________________________________________ >Owasp-modsecurity-core-rule-set mailing list >Owasp-modsecurity-core-rule-set@lists.owasp.org >https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
