ModSecurity Advanced Topic of the Week: Integrating IDS Signatures

Snort Web Attack Rules

You may be familiar with the Emerging Threats project. They have a few Snort rules files related to known web application vulnerabilities and attacks:

• emerging-web_server.rules
• emerging-web_specific_apps.rules

Identifying attacks against known vulnerabilities does have value in the following scenarios:

1. If you happen to be running the targeted application, it can raise the threat level, lessens false positives and ultimately provide increased confidence in blocking.
2. Even if you are not running the targeted software, you may still want to be made aware of attempts to exploit known vulnerabilties regardless of their chances of succeeding.

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;) 

Accuracy Concerns

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:

1. The injection point accuracy is not ideal. As the rule is using the older Snort "uricontent" keyword, what happens if the vehiclelistings.asp page also accepts POST payloads? This would mean that the vehicleID parameter may actually be passed in the request body and not in the query_string. This would result in a false negative.
2. The regular expression is not only applied to the vehicleID parameter data. The rule is only triggering if these three pieces of data exist in the request stream and not if the pcre data is found only within the vehicleID parameter payload.
3. The regular expression is not comprehensive. When looking at the pcre data, we can see that this is only looking for a small subset of sql injection attack data. There are many other types of SQL injection attack payloads that would by pass this basic regex. The result is that the Snort rule writers have to create many copies of this rule, each with different regex data.

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.

Integrating IDS Signatures into the CRS

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.

Using Anomaly Scoring Mode with the CRS

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:

1. tx.%{rule.id} - uses macro expansion to capture the rule ID value data and saves it in the TX variable name.

2. WEB_ATTACK/SQL_INJECTION - captures the attack category data and saves it in the TX variable name.

3. %{matched_var_name} - captures the variable location of the rule match and saves it in the TX variable name.

4. %{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.

Converting Snort Signatures in ModSecurity Rule Language

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.

SpiderLabs Research (SLR) Converted Signatures in the CRS

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:

• SQL Injection (sqli)
• Cross-site Scripting (xss)
• Remote File Inclusion (rfi)
• Local File inclusion (lfi)

We have also broken out the following application packs:

• WordPress
• Joomla
• PHPBB

If you are running one of these applications, it is highly recommended that you activate these rules.