SANS released their 6th edition of the @RISK Weekly News Letter. In it, there were a total of 44 new web application vulnerabilities identified. Keep in mind that almost all of these vulnerabilities (I didn't get a chance to verify each and everyone of them) can be mitigated with the use of the Core Rules. For example, take this specific vulnerability:
07.6.37 CVE: Not Available Platform: Web Application - SQL Injection Title: ExoPHPDesk FAQ.PHP SQL Injection Description: ExoPHPDesk is a web-based help desk application. It is prone to an SQL injection issue because it fails to sufficiently sanitize user-supplied data to the "id" parameter of the "faq.php" script before using it in an SQL query. ExoPHPDesk versions 1.2.1 and earlier are affected. Ref: http://www.securityfocus.com/bid/22338
If you go to the SecurityFocus page and click on the "exploit" link you will see this example URL attack:
http://www.example.com/faq.php?action=&type=view&s=&id=-1'%20union%20select%200,concat(char(85),char(115), char(101),char(114),char(110),char(97),char(109),char(101),char(58),name,char(32),char(124),char(124),char(32), char(80),char(97),char(115),char(115),char(119),char(111),char(114),char(100),char(58) ,pass),0,0,0,0,0%20from%20phpdesk_admin/*
If you were to send this request to a host that is protected by ModSecurity + the most recent release of the Core Rules, it would be identified by the following rule -
# SQL injection SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}? \b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe |cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|var iant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresul tset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bse lect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomou s_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\ b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|( ?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|m sdasql|dbo)')" \ "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog, msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"
The resulting alert message would look like this:
[Wed Jan 17 11:01:16 2007] [error] [client 192.168.10.10] ModSecurity: Warning. Pattern match "(?:\\\\b(?:(?:s(?:elect\\\\b(?:.{1,100}?\\\\b(?:(?:length|count|top)\\\\b.{1,100}?\\\\bfrom| from\\\\b.{1,100}?\\\\bwhere)|.*?\\\\b(?:d(?:ump\\\\b.*\\\\bfrom|ata_type)|(?:to_(?:numbe|cha)| inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:id. [id "950001"] [msg "SQL Injection Attack. Matched signature <union select>"] [severity "CRITICAL"] [hostname "www.example.com"] [uri "/faq.php?action=&type=view&s=&id=-1'%20union%20select%200,concat(char(85), char(115),char(101), char(114),char(110),char(97),char(109),char(101),char(58),name,char(32),char(124),char(124), char(32),char(80),char(97),char(115),char(115),char(119),char(111),char(114),char(100),char(58) ,pass),0,0,0,0,0%20from%20phpdesk_admin/*"] [unique_id "lqn99sCoChsAAHpfWokAAAAA"]
One very important note here:
By default, this SQL Injection rule is inheriting the following SecDefaultAction directive in the modsecurity_crs_40_general_attacks.conf file -
SecDefaultAction "log,pass,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase"
This means that while it did identify the attack, it did not block it. Your best course of action when implementing Core Rules is to run it with - SecRuleEngine DetectionOnly - until you have verified that there are no false positives in your environment. Afterwhich, you should change the SecDefaultAction settings within the rules files to actually use the "deny" action in order to prevent the attacks.
It is a good idea to periodically test out these types of exploit requests to ensure that your ModSecurity installation is functioning properly.