ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: August 2007

Web Services Security

NIST has released a new guide on securing Web Services. It is a pretty good read for anyone who is planning to run WS, specifically Appendix A which lists Common WS Attack categories such as:

  • Reconnaissance Attacks
  • Privilege Escalation Attacks
  • Attacks on Confidentiality
  • Attacks on Integrity
  • Denial of Service Attacks
  • Command Injection
  • Malicious Code Attacks

Protecting Web Services with ModSecurity

If you compile ModSecurity 2.x with XML support (with libxml2) and activate the file in httpd.conf, you can gain some protection for your WS traffic. While ModSecurity can not prevent every WS attack category listed above, it can certainly help to prevent a large number of the common HTTP attacks that now simply riding in the XML payloads.

XML Support in the Core Rules

Version 1.4 build 2 of the Core Rules introduced support for inspecting the the XML payloads of Web Services transactions. You can identify this by the inclusion of the XML:/* data in the variable listing. An example rule is listed below:

# Email Injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "[\n\r]\s*(?:to|bcc|cc)\s*:.*?\@" \
        "t:none,t:lowercase,t:urlDecode,capture,ctl:auditLogParts=+E,log,auditlog,msg:'Email Injection Attack. Matched signature <%{TX.0}>',,id:'950019',severity:'2'"

Since the Core Rules offers generic detection and does not tie specific attack payloads to specific parameters, the XML:/* variable is somewhat similar to the REQUEST_BODY payload in that ModSecurity will treat it as one large piece of data. This results in ModSecurity searching the entire XML payload looking for rule matches. For those ModSecurity users who are familiar with the 1.9.x branch, this is similar to the SecFilter rule processing where it performs a wider search for attacks as it does not know exactly where the input vectors are located. The side-effect is that there may be a performance hit if you WS XML payloads are large. If this is the case in your environment, they you will want to create some custom XML rules.

Custom XML Rules

ModSecurity can also be used to create custom rules for your WS application. Not only will this make the protection stronger and lowering the false positive rate, but you will also gain a performance boost when you specify full XPath locations in the variable list vs. the generic XML:/* variable that the Core Rules utilizes. We have created a use-case document entitled Securing Web Services with ModSecurity2 that will help to provide you with some examples of how to setup custom WS rules. Taking the previous Core Rule example, if we customize it for our WS application that is running at "/axis/getBalance.jws" and has one input parameter called "id", then the new rule would look something like this -

<Location /axis/getBalance.jws>
SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id/text() "[\n\r]\s*(?:to|bcc|cc)\s*:.*?\@" \
"t:none,t:lowercase,t:urlDecode,capture,ctl:auditLogParts=+E,log,auditlog,xmlns:soap=http:// \,xmlns:q1=http://DefaultNamespace,msg:'Email Injection Attack. Matched signature <%{TX.0}>',id:'950019',severity:'2'"

Notice the bolded portions of the ruleset where we have updated the XML variable to include a full XPath to our "id" input parameter and we also specified two xmlns actions to help ModSecurity to appropriately parse the payload.

Virtual Patching During Incident Response: United Nations Defacement

Virtual Patching is a policy for a web application firewall (in this case ModSecurity) that is able to identify attempts to exploit a specific Website vulnerability. ModSecurity analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the target Website. The end result is that even if a vulnerability still exists within the application’s source code, the virtual patch will protect against clients attempting to exploit it.

Virtual Patching is an extremely valuable technique that can be used to provide immediate protection against identified vulnerabilities. The trick here, however, is that you first must identify them! You can’t really create a patch if you don’t know what the problem is. There are six main processes that may yield vulnerability information that you can then take action on by virtually patching them:

  • Vendor contact (e.g. pre-warning)
  • Public disclosure
  • Bug report to the development team
  • Vulnerability assessment (internal or external)
  • Code review
  • Security incident

All of these scenarios are somewhat similar in that they all provide vulnerability information in reports of some sort. The only exception is that last one, a Security Incident. This is a unique situation in that there are no ifs, ands or buts involved in the discussions as to whether or not you need to respond to this issue. Any sort of lead time that you may have been counting on for a normal patching process, source code fix or system outage is suddenly thrown out the windows as proper Incident Response steps require you to act immediately. This is where Virtual Patching can prove to be invaluable.

Want a real life example?

In case you missed it, the United Nations (UN) website was recently defaced by a defacement trio known as "KEREM125 M0STED AND GSY." They defaced the site by adding html text to the speeches page. An archived screen shot is located here - notice the text under the "Latest speeches" window. And then here on the specific speech page.

While the details of the specific attack vector can not be 100% confirmed, it is suspected that the attackers used an SQL Injection vulnerability. A software developer named Giorgio Maone chronicled this incident on his Blog site. Maone partly deduced that SQL Injection was the likely attack vector by the missing apostrophe/single-quote in the word "dont" in the defacement text. Single-quotes are normally a key component of creating proper SQL query syntax and it is assumed that attempting to include it in the text would have complicated the SQL Injection attack. Maone also showed that the "statID" parameter for the statments_full.asp page is the most likely candidate for the attack as this URL – "'" – reveals the following DB error message:

ADODB.Recordset.1 error '80004005' 
SQLState: 37000
Native Error Code: 8180
SQLState: 37000
Native Error Code: 105
[MERANT][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ''.
[MERANT][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.
/apps/news/infocus/sgspeeches/statments_full.asp, line 26 

UN Incident Response Issues

Once the defacement was identified, the main UN site was taken offline and the following message was presented to clients:

This site will be temporarily unavailable due to scheduled maintenance.

After a number of hours, the site came back online. Unfortunately, vulnerability had not been patched as the same error message could be generated. It seemed that there was some sort of basic filter in place that attempted to filter out the single-quote character, however this is not a sufficient fix as there are SQL Injection queries that do not rely on this character. There is also the possibility of bypassing this filter by using the char() function. A short time later, the entire site was offline and presented clients with this message:

The UN website is undergoing urgent maintenance and is currently unavailable. Please check back in a short while.

When the site did come back online the Speeches section was not available and the same old vulnerability was still present...

What was happening?

We can only speculate at this point as to what was happening behind closed doors in the UN Incident Response team meetings, however they obviously had difficulty with addressing the standard "Eradication Phase" of the issue. When the choice is either being totally offline while waiting for the source code to be fixed vs. putting the site back online and monitoring the logs more closely for issues, the latter will always win out.

How a Virtual Patch could have helped

Looking at the URL again, we can narrow down the issue to the statments_full.asp application and specifically to the statID parameter. Looking at the normal, expected values associated with the statID parameter you can see that the data should only be digits. The following ModSecurity Virtual Patch could have been used to fix this issue by implementing a positive security ruleset:

<Location /apps/news/infocus/sgspeeches/statments_full.asp>
SecRule &ARGS "!@eq 1"
SecRule ARGS_NAMES "!^statid$"
SecRule ARGS:statID "!^\d{1,3}$"

This rule uses the normal Apache Location directive as a container for the ModSecurity rules. Inside this location, we are enforcing the following three rules:

  • The statments_full.asp page will only accept 1 argument
  • The name of the argument must be statID (note that the rule uses all lowercase as there is certain transformation functions being applied to normalize traffic)
  • The value of statID can only be 1 to 3 numeric digits

If this rule were in place, the example URL provided above would have been denied with this alert message:

[Wed Jun 13 01:06:37 2007] [error] [client] ModSecurity: Access denied with code 403 (phase 2). Match of "rx ^\\\\d{1,3}$" against "ARGS:statID" required. [file "/usr/local/apache/conf/rules/modsecurity_crs_15_customrules.conf"] [line "4"] [hostname ""] [uri "/apps/news/infocus/sgspeeches/statments_full.asp?statID=105'"] [unique_id "lCFILsCoD4QAABWcDp4AAAAD"]

This Virtual Patch would have provided instant protection against this issue until the actual source code could have been update or fixed.

ModSecurity 2.1.2 Released

Today I released ModSecurity 2.1.2. This is the latest stable release of ModSecurity. The 2.1.2 release contains several small updates. Users are encouraged to upgrade.

Notable changes as follows:

  • Full-width Unicode is now decoded by the urlDecodeUni transformation function.
  • Under some conditions (notably with mod_deflate and some other filters) earlier versions of ModSecurity were not correctly intercepting requests that used internal subrequests.
  • Core Rules were updated to the latest version (1.4.3).
  • Avoid using the hidden visibility attribute on functions when building on Solaris and under Cygwin.
  • Some sections of the documentation have been enhanced and/or clarified.
  • The license has been clarified to be GPLv2.
  • Copyright notices were changed to Breach Security, Inc.

As always, send questions/comments to the user mailing list.  You can get the latest release, documentation and subscribe to the user mailing list from the ModSecurity web site,  See the CHANGES file in the distribution for a full list of changes.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries