You may be familiar with the Emerging Threats project. They have a few Snort rules files related to known web application vulnerabilities and attacks:
Identifying attacks against known vulnerabilities does have value in the following scenarios:
Here is an example ET rule for a known SQL Injection vulnerability in the 20/20 Auto Gallery Application:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID SELECT";
flow:established,to_server;
uricontent:"/vehiclelistings.asp?"; nocase;
uricontent:"vehicleID="; nocase;
uricontent:"SELECT"; nocase;
pcre:"/.+SELECT.+FROM/Ui";
classtype:web-application-attack; reference:cve,CVE-2006-6092;
reference:url,www.securityfocus.com/bid/21154;
reference:url,doc.emergingthreats.net/2007504;
reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2020_Auto_gallery; sid:2007504; rev:5;)
When reviewing this web attack rule, we can conclude that there is an SQL Injection vulnerability in the "/vehiclelistings.asp" page presumably in the "vehicle" parameter payload. This tells us WHERE the attack vector is located. There is then a regular expression check that looks for specific sql data which tells us WHAT it is looking for. Upon deeper analysis, however, we find a few acccuracy concerns:
So, the question becomes, what is the true value of these types of snort rules? The value lies with identifying a known attack vector location (injection point). We can leverage this data in the CRS by converting the ET Snort rule into a ModSecurity rule and by using Anomaly Scoring.
As stated in the previous section, the true value of the IDS web attack rules is confirmation of a known attack vector location or injection point for a specific attack category (such as SQL Injection). The ModSecurity Core Rule Set uses the concept of "attack payload detection" where it has many different methods of identifying malicious payloads where ever they may exist. It does not, however, know if this is a known vulnerable injection point. The result is that there is a higher degree of false positives. The ideal scenario is to use both the CRS generic detection along with the known attack injection point intelligence from the IDS signatures.
In a previous blog post outlining Traditional vs. Anomaly Scoring Modes, we highlighted the main benefit of Anomaly Scoring - increased intelligence. Not only are more rules able to contribute to an anomaly score, but each rule also saves valuable meta-data about rule matches in TX variables. Let's look at CRS rule ID 959514 as an example:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bselect\b.{0,40}\buser\b" \
"phase:2,rev:'2.0.9',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,
ctl:auditLogParts=+E,block,msg:'Blind SQL Injection Attack',id:'959514',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',
tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'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}"
The bolded setvar action is the key piece of data to understand. If a rule matches, then we initiate a TX variable that will contain meta-data about the match:
tx.%{rule.id} - uses macro expansion to capture the rule ID value data and saves it in the TX variable name.
WEB_ATTACK/SQL_INJECTION - captures the attack category data and saves it in the TX variable name.
%{matched_var_name} - captures the variable location of the rule match and saves it in the TX variable name.
%{tx.0} - captures the variable payload data that matched the operator value and saves it in the TX variable value.
If we look at the debug log data when this rule is processing of a sample request, we see the following:
Executing operator "rx" with param "\\bselect\\b.{0,40}\\buser\\b" against ARGS:comment.
Target value: "i need to select a new user for my fantasy football team - who should i pick"
Added regex subexpression to TX.0: select a new user
Operator completed in 24 usec.
Ctl: Set auditLogParts to ABIFHZE.
Setting variable: tx.msg=%{rule.msg}
Resolved macro %{rule.msg} to: Blind SQL Injection Attack
Set variable "tx.msg" to "Blind SQL Injection Attack".
Setting variable: tx.sql_injection_score=+%{tx.critical_anomaly_score}
Recorded original collection variable: tx.sql_injection_score = "0"
Resolved macro %{tx.critical_anomaly_score} to: 5
Relative change: sql_injection_score=0+5
Set variable "tx.sql_injection_score" to "5".
Setting variable: tx.anomaly_score=+%{tx.critical_anomaly_score}
Recorded original collection variable: tx.anomaly_score = "0"
Resolved macro %{tx.critical_anomaly_score} to: 5
Relative change: anomaly_score=0+5
Set variable "tx.anomaly_score" to "5".
Setting variable: tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}
Resolved macro %{rule.id} to: 959514
Resolved macro %{matched_var_name} to: ARGS:comment
Resolved macro %{tx.0} to: select a new user
Set variable "tx.959514-WEB_ATTACK/SQL_INJECTION-ARGS:comment" to "select a new user".
Resolved macro %{TX.0} to: select a new user
Warning. Pattern match "\bselect\b.{0,40}\buser\b" at ARGS:comment. [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "67"] [id "959514"] [rev "2.0.9"] [msg "Blind SQL Injection Attack"] [data "select a new user"] [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"]
The final bolded entry shows you the final TX variable data that is now at our disposal. This TX data tells us that there was an SQL Injection attack payload detected in a parameter called "comment". We can now use this type of data to corrolated with converted Snort attack signatures.
We can convert the Snort rule discussed above into a ModSecurity rule like this:
# (2007545) SpiderLabs Research (SLR) Public Vulns: ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID UPDATE
SecRule REQUEST_LINE "@contains /vehiclelistings.asp" "chain,phase:2,block,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalisePathWin,capture,nolog,auditlog,logdata:'%{TX.0}',severity:'2',id:2007545,rev:6,
msg:'SLR: ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID UPDATE',tag:'web-application-attack',tag:'url,www.securityfocus.com/bid/21154'"
SecRule &TX:'/WEB_ATTACK/SQL_INJECTION.*ARGS:vehicleID/' "@gt 0" "ctl:auditLogParts=+E,setvar:'tx.msg=%{tx.msg} - ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID UPDATE',setvar:tx.anomaly_score=+20,setvar:'tx.%{rule.id}-WEB_ATTACK-%{rule.severity}-%{rule.msg}-%{matched_var_name}=%{matched_var}'"
As you can see, the first SecRule is checking the request line data to make sure that it matches the vulnerable resource. We then run a 2nd chained rule that, instead of looking separately for the existence of the parameter name and a regex match, it simply inspects previously matched TX variable meta-data. In this case, if a previous CRS rules had already identified an SQL Injection attack payload in the "ARGS:vehicleID" parameter location, then the rule matches.
The SpiderLabs Research team is now including converted Emerging Threats converted web attack signatures within the OWASP ModSecurity Core Rules set in the slr_rules directory. There are rules grouped in the following attack categories:
We have also broken out the following application packs:
If you are running one of these applications, it is highly recommended that you activate these rules.