UrlScan v3.0 Beta Release

The IIS team has some street smarts when it comes to security.

We learned quite a few lessons the hard way back in 2001 with the outbreak of the CodeRed worm.  One of the lesser known facts about the Code Red worm is that the vulnerability it exploited was not actually in IIS itself.  It was an application that ran on top of IIS.  Since that application was distributed with IIS and was installed by default, this distinction did not matter to our customers.  IIS and CodeRed became associated with each other.

When we designed IIS 6, we took on the challenge of creating an environment to protect the server from vulnerabilities in applications we host.  Our steps to address this issue ranged from not installing any applications (or even IIS itself) by default on a server, to providing a low privileged environment to minimize damage should a vulnerability be found.  We also took a hard look at our engineering practices and changed the way we did things to minimize the chances for serious bugs in the IIS core code.

Our application of these lessons has withstood the test of time, with IIS 6 being recognized as one of the most secure server products ever released.  We've applied the same principles to IIS 7 - and even extended them.

But back in 2001, IIS 5 was the current version of the web server and we needed to address the issues without waiting for the next IIS release.  To do this, we released a set of tools with The IIS Lockdown Tool.  This package included tools to go over configuration settings across IIS and set them to secure values appropriate to the applications running on the web server.  It also included a runtime tool called UrlScan.

UrlScan installs as a filter on IIS and looks at incoming requests in real time.  It can then screen requests based on a set of general request properties.  For example, it can block overly long URLs or headers.  It can block requests with unexpected HTTP verbs or strings in the URL.

Because CodeRed depended on a long URL and requests to a particular component, UrlScan was able to stop it in its tracks.  While this was no substitute for an actual patch to the affected component, it did buy customers time and protected their servers until they could get patches installed.  Over time, UrlScan was so effective at its job that we built most of its features into IIS 7 in the form of the request filter module.

Today, in 2008, we find ourselves in a similar situation.  We are seeing a particularly nasty automated SQL Injection attack that is targeting our customers.  This attack defaces web servers and sends their clients off to malicious servers that attempt to install malware.  As before, the vulnerability does not exist in IIS - or any software from Microsoft.  In this case, the attack is exploiting vulnerabilities in customer developed applications.  And as before, the real fixes will need to come from the myriad developers of those applications.

Unfortunately, neither UrlScan nor the IIS 7 request filter have been able to mitigate these attacks.  The reason for this is that the payload is delivered in the query string.  For historical and some obscure RFC reasons, UrlScan never looked at the query string.  And since the request filter is based on UrlScan, it has the same limitation.

As an initial measure to help our customers, we have released some sample ASP and ASP.NET code that can be used with existing applications to filter out these attacks.  But both of these measures still require every affected page to be located and edited.

As our next measure, we are today releasing a beta for a new version of UrlScan - version 3.0 - that can reach these requests and block them.  This release includes a GoLive license, so you can deploy it on your production servers.  UrlScan version 3 is compatible with the configuration files for the existing UrlScan version 2.5, so you if you are already running UrlScan, everything will still work as it did - except you'll have new options.  Also, since its been just over 5 years since UrlScan 2.5 shipped, we've taken the opportunity to add some frequently requested features.  The new set of features in version 3 are:

• Support for query string scanning, including an option to scan an unescaped version of the query string.
• Change notification for configuration (no more restarts for most settings.)
• UrlScan can be installed as a site filter.  Different sites can have their own copy, with their own configuration.
• Escape sequences can be used in the configuration file to express CRLF, a semicolon (normally a comment delimiter) or unprintable characters in rules.
• Custom rules can be created to scan the URL, query string, a particular header, all headers or combination of these.  The rules can be applied based on the type of file requested.
• Support for 64 bit IIS worker processes.

We also have plans to update the IIS 7 request filter to add these features.  In the interim, UrlScan 3 is fully supported on IIS 7.

Please feel free to download the UrlScan version 3 beta for 32 bit or 64 bit and discuss it in the Security Forum here on iis.net.

Finally, it cannot be overstated that these tools are just an interim measure to buy time to fix the affected applications.  While they are effective against the current wave of automated attacks, they cannot protect against more directed attacks against a specific server.  The category of SQL Injection vulnerabilites is so broad that there are no known filter strategies that can block a determined hacker against application vulnerabilities.  There are many resources available for learning about SQL Injection attacks and prevention strategies.  One of the nicest collections of links I've seen has been published in MVP Harry Waldron on his blog here.