RSS Feed

OWASP Boston Slides and SPF Public Demo Site

The slide deck from the "Tamper Proofing Web Applications at Runtime" talk I gave last night at the OWASP Boston meeting are now available for download.

We also released version 1.0.1 of SPF earlier this week and have a public SPF demo site running .NET PetShop v4 from MSDN. More information on SPF can be found on its official page.


Key Principles in Writing Secure Code Webinar

We just wrapped up a webinar titled "Key Principles in Writing Secure Code" for one of our training partners, Intense School. The target audience was primarily folks involved with application development looking for an introduction to Application Security. Here are some of the key points covered in the presentation:

  • The OWASP Top Ten Web Application Vulnerabilities
  • .NET and Java Secure Coding Practices
  • The Secure Development Lifecycle
  • Tools for Hacking web applications

There are also a couple of hacking demos that target vulnerabilities in a sample banking web application. Check it out here. Enjoy!


Using SPF to Protect Against SQL Injection Worms

When SPF was first released last month, I knew it was a great protection mechanism to thwart attacks against applications running on IIS. What I didn't realize was that the most urgent gap that it fills is that of thwarting SQL injection worms.

Microsoft has pitched UrlScan v3 as a band-aid solution to protect against SQL injection worm attacks on classic ASP and ASP.NET applications. The reality is that UrlScan's capabilities to protect applications-level attacks are quite limited. Specifically, UrlScan is not able analyze POST data and lacks support for regular expressions. This combined with the inability to include or exclude specific URLs leaves many users unable to adequately protect their vulnerable applications. Unfortunately with UrlScan it's an all or nothing approach.

SPF overcomes both of these shortcomings. Unlike UrlScan, SPF is specifically designed to thwart application-level attacks. UrlScan is not. UrlScan was originally designed to protect IIS web servers from the onslaught of web server attacks that surfaced shortly after the turn of the millennium (i.e. Code Red, Nimda, etc). UrlScan is very effective as a server-level protection mechanism; however the reality is that it simply was not designed to be an application-level protection mechanism.

Last week, an updated beta of SPF was released which has been significantly optimized for performance in Black-List only configuration mode. I have come up with the following sample configuration which can be used to protect IIS6 applications from SQL injection attacks (applications hosted on IIS7 can also use this configuration). Keep in mind that these patterns are designed to prevent false positive hits while still allowing most sites to function; using blanket deny rules against strings like "exec", for example, won't work in most real-world situations (strings like this occur way too often in most free-text submissions). I experienced this first-hand when attempting to implement UrlScan on a customer website using the sample SQL Injection rules published on the IIS.NET Security Blog.

The Black-List only sample configuration for SPF is shown below:

<spfConfig logDirectory="c:\\temp\\logs" protectForm="false" protectUri="false"
protectQueryString="false" protectCookie="false" protectMode="Active"

<add extension=".asp" />
<add extension=".aspx" />

<add patternRegex="(select|grant|delete|insert|drop|alter|replace|
database|index|view|set)" applyTo="all" />
<add patternRegex="'?\\s+OR\\s.+=" applyTo="all" />
<add patternRegex="(--|;|*|@@|0x|DECLARE|..|.dbo.)" applyTo="all" />
<add patternRegex="(CAST|EXEC|CHAR)(%|()" applyTo="all" />
<add patternRegex="(s|x)p_" applyTo="all" />

If anyone has any additional ideas on good SQL attack patterns to look for, feel free to share your thoughts. Keep in mind SPF BlackListPatterns are not case sensitive and are applied to decoded request data. As always, this is not intended to be permanent solution for SQL injection (as opposed to fixing your code); however it certainly raises the bar for bad guys and will buy you some time to implement the optimal fix.


IIS Secure Parameter Filter (SPF) Released

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 CodePlex. 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.


Overview of "SQL Injection Worms for Fun and Profit" 

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.