We have publicly released the Beta version of IIS Secure Parameter Filter (SPF) on our tools page. SPF is an application security module specifically designed to thwart parameter-based attacks against applications running on Microsoft IIS web servers. SPF requires minimal initial configuration and does not require making any modification to the underlying application code.

Those of you who attended the “Protecting Vulnerable Applications with IIS7” talk which I presented at Black Hat earlier this month will recognize SPF as the module which I demonstrated. The version we released today works with both IIS6 and IIS7 and is written in managed .NET code.

So what exactly does SPF do? SPF provides two primary protection mechanisms which are each explained in more detail below.

Tamper Protection

The tamper protection capabilities of SPF are primarily designed to thwart authorization attacks. Tamper protection works at the following levels:

• URI Protection - Protected URI’s require a cryptographic token to access. The only way to obtain a valid URI token is for the application to present you with a link to the URI. This is primarily designed to thwart direct browsing attacks where users can forcefully request pages for which they are not entitled.

• Query String Protection - Protected query string values are validated using a cryptographic token which ensures they were not tampered with. This protection is designed to secure embedded query string values from manipulation.

• Form Field Protection - Protected form fields that contain embedded values (i.e. Hidden Fields and Select Lists) are encrypted to prevent un-authorized viewing or modification by malicious users.

• HTTP Cookie Protection - Protected cookies are encrypted to prevent un-authorized viewing or modification by malicious users.

SPF tokens can also be bound to the calling user and set to expire, resulting in the ability to protect against Cross-Site Request Forgery and thwart certain types of hijacking, replay and cross-site scripting attacks.

Malicious Input Filtering

Malicious input filtering (referred to as Black List Protection) is designed to identify parameters that include known attack patterns. SPF supports Black List pattern matching against Query Strings, Post data, and Cookie values.

In some ways, this functionality can be compared to existing server filters like Microsoft’s URL Scan, but SPF provides much more flexible capabilities. Black List Protection was originally not within the scope of SPF’s protection mechanisms, however with the recent wave of SQL Injection worms it became apparent that URLScan (specifically the recently released 3.0 Beta version) is not sufficient for protecting web applications from attack.

URLScan is a good server-level protection mechanism that has been adapted to provide basic web application protection whereas SPF is designed specifically to defend web applications and therefore can provide more comprehensive protection against harmful input. SPF’s Black List Protection provides the following:

• Regular Expression Support - Provide a powerful mechanism for defining malicious input patterns
• Flexible Request Entity Coverage – Black List patterns can be applied to any combination of Query Strings, Post data or Cookie values. This level of HTTP request coverage is especially critical as SQL Injection worms become more advanced and move beyond exploiting Query String parameters. Specific URLs can also be excluded from Black List coverage for greater flexibility.

SPF is currently available for free download and use from the GDS Tools page. The current Beta of SPF provides full protection for any application running on IIS7 and for ASP.NET applications running on IIS6. Non-ASP.NET applications on IIS6 will be limited to only the Malicious Input Filtering (Black-List) capabilities of SPF. A detailed administration guide is included with the download.

For those of you who didn’t catch my turbo talk at Black Hat in Las Vegas, and especially those of you who looked at the slides and demo in my previous blog post and had no idea what the talk was about, I thought I’d put together a short summary of what was covered, and what I demonstrated.

I began my presentation by discussing the mass SQL Injection attacks that started earlier this year (see Internet Storm Center coverage from the start of the year), originally out of China, but now out of Eastern Europe as well. The profit motivation for these attacks is fairly obvious - inject JavaScript malware into a site’s HTML. The attacks exploit SQL Injection vulnerabilities to insert JavaScript into the database that is then rendered back into web pages. Botnets are often used to randomly attack website pages on the Internet (chosen using Google, for example) with a generic SQL Injection attack. The attacks have one shot at success - it either works or it doesn’t. The major upside of using a botnet is that even a low success rate can be devastating as they can still compromise hundreds of thousands of pages. Even worse, the indiscriminate nature of botnet attacks make it so potential victims no longer have to wander off to the deep dark corners of the Internet to face the possibility of some malicious content being installed on their machines, because any site could potentially be infected.

There are some other profit motivations that to date we haven’t seen exploited. Namely, unlike the more common botnet attacks that seem to largely target home users for their personal information and details, the mass SQL Injection attacks have a different target - websites developed by organizations and businesses, large and small. Some of which may have some very interesting information, such as customer data and (regardless of whether it is supposed to be there according to the PCI DSS) credit card information. Another target are websites that are on DMZ’s behind outer perimeter controls (e.g. firewalls), and therefore may provide a useful pathway into an organization’s network, and all of the interesting information and data residing there.

Building on these attack scenarios, I then speculated on aspects of the current mass SQL Injection attacks that could lead to more serious exploitation. What I came up with was a self replicating SQL Injection worm, and this is what was demonstrated on stage at Black Hat.

How does the Proof of Concept SQL Injection Worm Work?

For the moment it is Microsoft SQL Server specific, largely because the functionality leveraging the underlying operating system is straight forward to access in SQL Server. The worm looks at the IP address it is on, and if it is an RFC 1918 private IP range it will scan the subnet looking for other web servers on port 80. When it finds a website, it does a fairly simple crawl of the entire site, and then parses through the HTML code to identify query strings with parameters, as well as forms in the HTML. The worm then tests each parameter in succession for trivially identified SQL Injection vulnerabilities. If a parameter is vulnerable, the worm will then run through the following tests:

• is the back end Microsoft SQL Server?
• are stored procedures executable?
• is the xp_cmdshell extended stored procedure executable?

If those tests succeed, the worm uses the xp_cmdshell functionality to upload a copy of itself (i.e. the payload) onto the database server. It does this by encoding the payload as a text file, echoing it up line by line, and unpacking it on the destination server using the debugger that ships with every Windows installation by default - debug.exe. Then, presuming it all worked, the reassembled worm is executed, and the spread continues. And that is all this proof of concept worm does - spread. All of this worked quite well live on stage, with the exploit to upload process taking about 2-3 minutes for my test network, enabling me to show a number of the worms executing in memory (as the worm doesn’t have any facility to detect whether a machine is already infected).

Yes, this particular worm does rely on an insecure configuration being present - namely that xp_cmdshell is executable. By default this is not available on SQL Server 2005, and won’t be executable unless the website has been explicitly granted privileged access to the database server, so not all vulnerable sites will be exploited by the worm. However, there are plenty of sites that are configured insecurely, running previous versions of SQL Server (that are much easier to misconfigure), and let’s not forget xp_cmdshell is also available and potentially exploitable on sites running a Sybase backend. After all, even if only one in ten sites are in this configuration, we will still have tens of thousands of vulnerable sites.

To wrap it all up, my Black Hat presentation demonstrated one particular way that things could get much worse with SQL Injection worms. Leveraging operating system access (if present) is only one potential way to wreak havoc on the Internet. There are lots of others - I for one will be very interested to see where those clever folks in China and Eastern Europe take the mass SQL Injection attacks in the near future.

Well, I’m offstage now having just presented my talk on “SQL Injection for Fun & Profit” at Blackhat in Las Vegas. One of the main aims of the talk was to provide more coverage on the mass SQL injection attacks that started earlier this year (and are still going on). The Internet Storm Center has some good discussion and coverage on this topic from earlier this year. The other aim was to point out some of the ways it could have, and probably will be in the near future, much much worse.

You can find a copy of the slides that were presented here, as well as a flash video of the demo that was done of the self replicating SQL Injection worm I wrote for this talk.