UrlScan v3.0 Beta Release

Posted: Jun 24, 2008  42 comments  

Average Rating

Share this Post

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.

Comments

Well done. I have been waiting for this for ages and I haven't used URLscan for years as this feature was not available and previously now directory traversing (one of the main thing URLscan stopped initially) is less of a problem as IIS deals with it natively.

It has always been a disappointment to me that URLScan didn't do query strings even the explanations or this (blogs.msdn.com/.../why-urlscan-ignores-querystring-for-denyurlsequences.aspx) didn't seem to wash much. I want the control.

In fact just the yesterday I was complaining on the iis.net forums that urlscan 2 didn't do query strings and what a shame this was.

It means now I can tailor protection for a SQL injection attack as in the related post. Obviously you have careful (as you do with any installation of URLscan) as you do not want to block legitimate pages.

I would advise anyone deploying URLscan to also run through your legitimate site with urlscan in test/dev/staging with a link analyser/stress tester. If you do not have these environments then set up a dummy version of your site and in another sub-domain get wwwtest.mysite.com and run through the testing on that. With the link analyser/stress tester you can all links and cross referencing this with the URLscan logs to tune you keywords/settings. For the larger sites you will find that there are many legitimate cases that are rejected when you use seemingly 'standard' filters. I know from experience of deploying (or attempting to deploy) previous versions of URL scan that things will be rejected and you want to test this as much as possible before going rolling out to production.

You could easily find that your site having say 'select' or 'table' in the query string or lengths over a certain size. When limiting to lengths over a certain size (a really useful feature for the query strings) compare to you previous (months) logs to see what behaviour your site displays (running query analyser before and to make sure you have populate the logs with more comprehensiveness urls). Enter you IIS logs into a database or use logparser and run queries on the length of the URI stem and URI string fields.

Is there a way to feed all the legitimate pages in the logs (all requests that succeed - 2xx, 3xx http status) through urlscan to emulate the behaviour of what the scan would do with the previous real-world behaviour of the site?

This would help admins better prepare for deployment and the feasibility of deploying to many real world environments.

Congrats again. I look forward to deploying it. I'll report back any findings and a deployment guide maybe.

Jun 25 2008 by Rovastar

Well it's about time. See forums.iis.net/.../1144387.aspx  

Jun 25 2008 by Madness80

Run this codes in POST/GET

';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

'';!--"<XSS>=&{()}

If your system pass, it will probably be secure enough.

Jun 26 2008 by Anonymous

since installing urlscan beta 3 we are experiencing problems in our application pools.

some of the asp pages are not loading correctly after a time as if rejected asp requests are being stored in the asp compiled templates area. so any subsequent calls to the asp page displays a blank page.

the only fix at the moment is to recycle the application pool.

is there are flag to help with this problem or do we have to turn off asp compiled templates in iis or is this a possible bug?

Jul 18 2008 by Powerf

Hi. Thanks for this version of URLScan.  When is it going to be our of Beta?  What's the release date or did I totally miss something on the release date?  Thanks!

Aug 14 2008 by Anonymous

good

Oct 18 2008 by Anonymous

have a great working..Tenks for you .

http://www.oyunoynatr.org/pet-rescue-saga-oyna.html">www.oyunoynatr.org/pet-rescue-saga-oyna.html = http://www.oyunoynatr.org/

Jan 30 2013 by SussShef23

www.oyunoynasak.net   oyunlar oyna bedava oyun

Jun 21 2013 by bucuruk

http://www.oyunoynasak.net   oyunlar oyna bedava oyun

Jun 21 2013 by bucuruk

Submit a Comment

  • Plain text is accepted.
  • URLs starting with http:// are converted to links.