Nazim's Security Blog

Safely handling untrusted XML server-side

naziml — Wed, 13 Mar 2013 16:11:00 GMT

If you didn't think that processing XML on the server side can lead to a Denial of Service, Information Disclosure or even Remote Code Execution, read on. The issues discussed here are include a class of issues that is commonly referred to as XML External Entity vulnerabilities (XXE), but are not limited to this. If you are NOT processing untrusted XML and the data comes from a trusted source this article doesn’t really apply for you but is still good to enforce safe usage for hygiene.

Most would consider XML as simple markup data, but you should actually consider it a ‘language’ that actually has powerful runtime features. These runtime features could be enabled on the server-side even if their use is not intended, and this is what unwittingly leads to XML based vulnerabilities on the server side. Following are a few of the classes of issues you could run into with XML processing.

Denial of Service

XML allows you to define entities that are essentially tokens that get replaced at runtime. Some of these are well-known, like > which would get replaced by the greater than sign ‘>’. But you can actually custom define entities as in the example below.

<!DOCTYPE doc [<!ENTITY name "Nazim">]>
<doc>
&name;
</doc>

During XML pre-processing, this XML would essentially become

<doc>
Nazim
</doc>

But we can go further and define entities that reference other entities, like

<!DOCTYPE doc [
   <!ENTITY greeting “Hello">
   <!ENTITY name “Nazim">
   <!ENTITY sayhello “&greeting; &name;">
]>
<doc>
    &sayhello;
</doc>

So now the XML pre-processor has to go through multiple stages of entity expansion.

You have probably put 2 and 2 together at this point and see the issue already. Since this is essentially a tree structure, I can grow the number of nodes to pre-process exponentially. So something like the doc below even though small in size (<1KB) will expand out to a billion lols and can take up almost 3GB in memory. This is commonly referred to as the billion laughs attack and you can read more about it in this MSDN article.

<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

Information Disclosure

Entity expansion is not limited to string literals though. It could very well refer to external data like the example below.

<!DOCTYPE doc [
    <!ENTITY win SYSTEM “c:\windows\win.ini">
]>
<doc>
    &win;
</doc>

If this document is somehow reflected back to the client it would result in disclosing information on the server that a client wouldn’t have access to.

Remote Code Execution

I think this is best shown by directly diving into an example.

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt"
    xmlns:user="http://example.com/ns">
<msxsl:script language="C#" implements-prefix="user">
    <![CDATA[
    public string Code()
    {
        return Environment.MachineName;
    }
    ]]>
</msxsl:script>
<xsl:template match="/">
    <xsl:value-of select="user:Code()"/>
</xsl:template>
</xsl:stylesheet>

Here we have an XML style sheet that essentially has some code that is run as part of applying the style sheet. Imaging replacing the code highlighted with a payload of your choice, including things like a network scan :)

Preventing XML Entity Attacks

You essentially want to disable <!DOCTYPE> definitions (DTDs) when parsing untrusted XML. There are many APIs, that are not safe by default in this respect and you need to explicitly disable DTD resolution on an XML document. See below for API specifics.

Preventing XSL Attacks

This is pretty much the same as above and you want to disable DTD and XSL script support. See below for unsafe API specifics.

Safe XML API usage on Windows/.NET

The list below was accurate at the time this article was compiled. It is possible that updates to components may have changed the defaults, so it is always better to test your usage.

System.Xml.XmlDocument

Load and LoadXml UNSAFE unless you pass a safe XmlReader (DTD disabled) into it during initialization.
InnerXml is NEVER SAFE.

System.Xml.XmlTextReader

UNSAFE by default in .NET 3.5 and below.

You need to set ProhibitDtd=true to make this safe.

.NET 4.0 and above are safe be default.

System.Xml.Xsl.XslTransform

UNSAFE as it supports both entities and XSL script.

System.Xml.Xsl.XslCompiledTransform

Safe for XSL script since this is blocked by default.
UNSAFE for entity expansion unless a secure resolver is specified.

Pass an instance of XmlSecureResolver or null

System.Web.UI.WebControls.XmlDataSource

NEVER SAFE – supports both entities and XSL script.

MSXML 5 and below

UNSAFE by default
Need to set ProhibitDtd=true, AllowXsltScript=false and AllowDocumentFunction=false

MSXML 6

Safe by default

Resources

OWASP XXE Page

Adobe Reader XXE Attack

Attacking server side XML parsers (PDF)

Is IIS vulnerable to the THC SSL DoS attack tool?

naziml — Wed, 02 Nov 2011 21:22:25 GMT

There was a recently released tool by THC that can be used to launch Denial of Service (DoS) attacks against servers hosting SSL sites. Besides the traditional bot-net Distributed Denial of Service (DDoS) class attacks, this tool lets a single client use client SSL renegotiation to cause server DoS.

IIS versions 6 and above are NOT affected by the renegotiation DoS attack since http.sys (http driver on Windows Server) disallows client initiated renegotiation in SSL and sends a TCP RST anytime a client attempts a renegotiation. The attack tool will open a new TCP/IP connection for each SSL handshake in this case, making it no different than a regular DDoS attack that would need very large client side resources to execute.

The information used to carry out the attack in this tool is easily mitigated and has been known publicly since March 2010 in the IETF TLS Lists. The gist of all these attacks is that it takes more resources on the server side to complete an SSL handshake than it does on the client side. So any effective front firewall mechanism that is employed to track such requests and clients and block them early on, provide adequate protection against this kind of attack.

Unlike IIS, some other services that use SChannel to perform SSL on Windows Servers may not disable client initiated renegotiation. To globally disable this for all servers and services that use SChannel, follow the guidelines on http://support.microsoft.com/kb/977377 to disable client initiated renegotiation globally on the server.

Is IIS susceptible to the Apache Range Header DoS attack?

naziml — Thu, 25 Aug 2011 21:17:26 GMT

A recent disclosure on seclists.org about a Denial of Service attack against Apache web servers has raised concerns about whether IIS web servers are affected. We will quickly talk about the issue and its impact on IIS web servers in this post.

Issue

HTTP requests give you the ability to send a request to a web server and elicit only a portion of the response by using the 'Range' header. For example, if you are requesting a text file, but only want the first 500 bytes, you would send the request with the following HTTP header: Range: 0-499 \r\n. This feature allows for multiple comma-separated ranges to be specified within the header, so I could get the same result as above by specifying Range: 0-199,200-499.

This feature can theoretically be abused by specifying several ranges that will cause server-side processing of the response to consume excessive resources. So if I sent Range: 0-,0-,0-,0-,0-,0- the server would produce a response by replicating the resource requested six times and consuming resources in the process of concatenating the response. So it is possible to send a malicious request and cause a Denial of Service on the server side.

Is IIS affected?

IIS 6 and above are NOT affected because IIS only allows up to 5 ranges within any HTTP request in the Range header. The resources consumed on the server side for such a request is not sufficient to cause a Denial of Service. IIS 5, however, does not have this limitation and is hence affected by such a vulnerability. IIS5 however is not supported by Microsoft anymore, and if you still have IIS 5 web servers deployed you should consider upgrading to the latest Windows Server version.

World IPv6 Day and IIS 7

naziml — Tue, 07 Jun 2011 18:03:37 GMT

Wednesday June 8 2011 is World IPv6 Day and there will be plenty of representation by IIS7 on the Windows Server side. From Microsoft we will have participation in this event by Microsoft.com, Bing.com and Xbox.com; all of which run IIS7 web servers on their front end.

Using IPv6 with IIS7 is trivial and intuitive, and we have deep integration of IPv6 features into the IIS product. From creating site bindings to logging to security features like IP Restriction, IIS has full support for IPv6 including validation in our management interfaces. For more information on using IPv6 with IIS7 please visit http://blogs.iis.net/nazim/archive/2008/05/03/using-ipv6-with-iis7.aspx.

Use of special characters like '%' ‘.’ and ‘:’ in an IIS URL

naziml — Mon, 18 Apr 2011 17:12:00 GMT

There are multiple times that we get questions about % and other special characters in the URL and what the expected behavior is in IIS. The behavior in IIS is very deterministic when it comes to these special characters, but to explain the behavior we will need to delve a little bit into both URL canonicalization and the different stages of request processing in IIS.

Usage of special characters in the URL first and foremost depends on the portion of the URL it is being used in. Here is a sample URL.

http://www.myserver.com:80/application1/foo.aspx?var1=1&var2=2, where
http:// is the protocol specifier
www.myserver.com:80 is the hostname where the port specification is optional
application1/foo.aspx is the request URI or the URI path
var1=1&var2=2 is the query string.

IIS does not perform any checks on the query string and considers this portion as a blob and does no encoding processing and is as such not very interesting for this discussion. Both http.sys (driver mode HTTP parser) and IIS considers the query string opaque. The only exception to this are filters like Urlscan, Request Filtering etc. These may additionally block characters depending on their configuration.

The request URI (URI path) above is the most interesting and there are several layers of validation that happen, the first being by http.sys, the second by IIS request filtering, third by IIS core, and then by any handler (like ASP.NET).

Layer 1: Http.sys (blocked characters = ‘%’)

Http.sys parses URLs in accordance with RFC 2396. You can however configure exceptions using the AllowRestrictedChars registry setting documented in KB 820129. This configuration will never allow a bare ‘%’ character though because it is expressly forbidden in the RFC section 2.4.2 which says:

“Because the percent "%" character always has the reserved purpose of being the escape indicator, it must be escaped as "%25" in order to be used as data within a URI. Implementers should be careful not to escape or unescape the same string more than once, since unescaping an already unescaped string might lead to misinterpreting a percent data character as another escaped character, or vice versa in the case of escaping an already escaped string”

Layer 2: IIS request filtering (blocked characters = ‘%25’, ‘.’, ‘%2b’)

IIS request filtering checks for a couple of things by default and the behavior is controlled by configuration. You can reference the following articles for details, Use Request Filtering and Using Urlscan. This filtering potentially processes both the URI path and the query string and could disallow things like:

Double escaping which involves the use of %25, which is an encoded ‘%’ sign. Also, ‘+’ characters are considered and encoded space even though it does not have a % in the beginning. So encoding this as %2b will also trigger this rule.
Non-ASCII high bit characters.
Dot in the URI path, where a request that contains a dot other than that for the resource extension will be rejected. Eg: http://foo/a.b/bar.aspx

Layer 3: IIS core (blocked characters = ‘:’)

There are no restrictions per se in IIS core, but there are a couple of things it does with physical file mappings that are produced from URL mappings.So for handlers like the static file handler that will serve out files, we will check for file paths containing the ‘:’ character to avoid ::$DATA like security issues that occurred in MS98-003 and MS10-065.

Layer 4: Handlers

This part depends on what handlers are being used in your request processing. So if you are using ASP.NET for instance, it could trigger request validation that could additionally block characters in both the URI path and the query string. If you are using Sharepoint, they have their own list of blocked characters as mentioned in KB 905231.

Security update released for FTP 7.0 and FTP 7.5 0-day

naziml — Tue, 08 Feb 2011 18:41:54 GMT

In the later half of December 2010, an FTP 7.X exploit was published on http://www.exploit-db.com/exploits/15803/.

We posted a risk assessment in a blog on the Security Research and Defense team’s blog http://blogs.technet.com/b/srd/archive/2010/12/22/assessing-an-iis-ftp-7-5-unauthenticated-denial-of-service-vulnerability.aspx

This issue now has a fix available http://www.microsoft.com/technet/security/bulletin/ms11-004.mspx. Please make note of the known issues for patching on Windows Server 2008 Server Core in http://support.microsoft.com/kb/2489256. The fix is available for both the Download Center version of FTP and the optional component in Windows 7 and Windows Server 2008 R2.

You can find more information on this issue on http://blogs.technet.com/b/srd/archive/2011/02/08/regarding-ms11-004-addressing-an-iis-ftp-services-vulnerability.aspx

Security update released for ASP.NET Padding Oracle Vulnerability

naziml — Wed, 29 Sep 2010 01:12:00 GMT

Microsoft has just released security bulletin MS10-070 with security updates for the issue. The updates are currently on Microsoft Download Center, but will be available through all other channels soon.

ScottGu has also blogged some FAQs on this security update.

It is highly recommended for customers using ASP.NET to apply the security update on their servers.

Update 1: ASP.NET Zero Day Vulnerability - Padding Oracle Exploit

naziml — Tue, 21 Sep 2010 02:12:00 GMT

ScottGu has posted some additional FAQs on http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

The Microsoft advisory has been revised with some additional content in the FAQs. http://www.microsoft.com/technet/security/advisory/2416728.mspx

The SRD blog has also been revised with some additional content. http://blogs.technet.com/b/srd/archive/2010/09/20/additional-information-about-the-asp-net-vulnerability.aspx

The Sharepoint team has a blog on some additional workarounds that you can employ for Sharepoint 2010. http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

ASP.Net zero day vulnerability - Padding Oracle exploit

naziml — Sat, 18 Sep 2010 03:03:00 GMT

An ASP.Net cryptograhic zero day was publicly disclosed today.

Microsoft has released an advisory to help customers understand the vulnerability and apply workarounds to secure their sites. The advisory is at http://www.microsoft.com/technet/security/advisory/2416728.mspx.

The Microsoft Security Response Center (MSRC) has released a blog at http://blogs.technet.com/b/msrc/archive/2010/09/17/security-advisory-2416728-released.aspx.

The Security Research & Defense (SRD) team at Microsoft has also released a blog that contains a script to help detect vulnerable installations. The blog is located at http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

You can check out more details on Scott Guthrie’s blog at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

> UPDATES HERE <

Fixes for several IIS issues released in September 2010 patch cycle

naziml — Thu, 16 Sep 2010 22:01:00 GMT

We just released a bulletin this September that addresses three IIS vulnerabilites. Two of these were responsibly discolsed, while one was publicly disclosed. The bulletin is on http://www.microsoft.com/technet/security/bulletin/MS10-065.mspx and contains the mitigations and workarounds in each case. The knowledge base articles for each of the three vulnerabilities are linked below and contain affected platform information.

CVE-2010-1899 [classic ASP]: Denial of Service: http://support.microsoft.com/kb/2124261/

CVE-2010-2730 [fastCGI]: Remote Code Execution: http://support.microsoft.com/kb/2271195/

CVE-2010-2731 [Authentication]: Elevation of Privilege: http://support.microsoft.com/kb/2290570/

Dynamic IP Restrictions Beta 2 released!

naziml — Tue, 24 Aug 2010 16:42:47 GMT

Yes, it has been a while since Beta was released, but Beta 2 is finally released! You can download Dynamic IP Restrictions Beta 2 from the links below.

Dynamic IP Restrictions 1.0 Beta 2 – x86

Dynamic IP Restrictions 1.0 Beta 2 – x64

For more details on the release make sure you check out the updated article on using Dynamic IP Restrictions. I will take the time to mark the distinctions between Beta and Beta2 versions in this post.

Splitting dynamic and static IP restrictions

Well, in Beta we were experimenting with the codebase and possible restructuring of features by combining static and dynamic IP Restrictions. This caused a bunch of setup issues and didn’t buy us much in terms of ease of use and configuration. So we have decided to let static and dynamic IP restrictions each live in their own module and configuration space for Beta 2 and this will remain as such moving forward to RTW. What this means is that:

You will need to uninstall the Beta version of Dynamic IP restriction before you can install Beta 2. Make sure to backup configuration before doing this!
Since static IP restrictions module was uninstalled during the installation of dynamic IP restrictions Beta, you will now have to re-install (re-enable) static IP restrictions module (IP and Domain Restrictions).

Negligible runtime performance impact

The other change, that will be invisible to the end user, is a complete rewrite of the code to make the runtime performance impact of the module almost 0, even if you are just serving static files from your web server. We feel that every web server should have this feature installed and enabled and this way we ensure that the dynamic IP restrictions module will have no performance impact on your server.

Removal of RSCA interface

In Beta, you could use our RSCA interface to see currently blocked IP addresses, but this is not much more than eye candy. The data presented through this is not really actionable, since this list is going to be highly dynamic by nature. This module has been designed as a security defense tool and keeping that in mind the right action to perform is to detect repeat offenders and block them using either the static IP restriction or the firewall. To do this you would need historic data and not just a snapshot of what is happening right now. We had strong feedback from Beta that mining the logs was much more meaningful.

Proxy mode

Requests coming to the web server from a proxy or firewall server usually has the IP address of the firewall or proxy server as the client IP address. This defeats the usability of dynamic IP restrictions module because client IP address to actual clients is now a many to one mapping. We now have a configuration option that will enable the module to use the first IP address in the X-Forwarded-For request header as the client IP address. This header is used as the de-facto mechanism of reporting originating IP address.

Server and site level configuration only

One of the main changes we had to make in the module to make it extremely performant is to restrict configuring this module to server and site level only. If you host multiple applications with extremely different request-response characteristics on the same site, you should move them to different sites on the same server to increase the effectiveness of the module.

I will have a blog/article on using LogParser to mine data from log output of dynamic IP restrictions soon.

Security fix for IIS Extended Protection released

naziml — Wed, 09 Jun 2010 18:56:42 GMT

Microsoft has just released a fix for the Extended Protection for Windows Authentication feature in IIS. The details about the issue are in security bulletin MS10-040.

Important things to note about the issue/fix:

The fix is only applicable if you have Extended Protection installed.
Windows 7 and Windows Server 2008 R2 have this feature in the OS. However all previous platforms require you to install KB 973917 to get this particular feature. So if you did not install KB 973917 on your Windows Server 2008 machine for example, you won't need this update.
The issue will occur only if you set Extended Protection tokenChecking flags to 'Allow' (partially hardened).
Your server configuration is NOT vulnerable if the Extended protection feature is not in use, i.e. tokenChecking=None, or your server is configured to a 'hardened' state, i.e. tokenChecking=Require. Your server is vulnerable on if it is configured to a partially hardened state, i.e. tokenChecking=Allow. In this state your server will allow Windows Authentication without a Channel Binding Token from clients that do not support it.

Blocking SQL injection using IIS URL Rewrite

naziml — Tue, 23 Mar 2010 16:36:00 GMT

We have had quite a few conversations about SQL injection on my blog, including Filtering SQL Injection from Classic ASP and Using Rules Configuration in UrlScan 3.0 to filter SQL injection. One of the shortcomings that we talked about was that UrlScan is not as flexible as some users want it to be since it does not have the ability to use regular expressions. Well the story changes quite a bit with IIS URL Rewrite module, that is capable of doing request and response rewriting based on regular expressions. For those weighing between URL Rewrite and UrlScan, URL Rewrite has more flexibility but UrlScan is a lot more performant, so choose depending on your needs and resources.

I have seen a lot of articles crop up with increasingly complex and voluminous rules for this, so I wanted to present something a little more simplified for folks to use. Thanks to Bala from the SQL Server Security team (who has written excellent MSDN documentation on preventing SQL injections in ASP) there is a simpler rule to use that will catch quite a few of the variants without any false positives for any valid requests that I have seen so far. Most of the widespread automated SQL injection attacks use a DECLARE->CAST->EXEC approach to executing their injection. If I were to just put 'CAST' in a deny list I would hit a lot of false-positives, e.g. if my Url contained the word 'casting'.By requiring a Declare ... Cast ... Exec structure we can drastically reduce the chances of a false-positive.

Here is the Regular Expression used:

[dD][\%]*[eE][\%]*[cC][\%]*[lL][\%]*[aA][\%]*[rR][\%]*[eE][\s\S]*[@][a-zA-Z0-9_]+[\s\S]*[nN]*[\%]*[vV][\%]*[aA][\%]*[rR][\%]*[cC][\%]*[hH][\%]*[aA][\%]*[rR][\s\S]*[eE][\%]*[xX][\%]*[eE][\%]*[cC][\s\S]*

Notice the the groupings in the brackets towards the beginning spell out DECLARE and that towards the end spell out EXEC. That should give you a good idea of how this regex is expected to work. To add this validation to the REQUEST_URI you could use configuration like that below in a web.config file.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Filter SQL injection" stopProcessing="true">
                    <match url=".*" />
                    <conditions>
                        <add input="{REQUEST_URI}" pattern="[dD][\%]*[eE][\%]*[cC][\%]*[lL][\%]*[aA][\%]*[rR][\%]*[eE][\s\S]*[@][a-zA-Z0-9_]+[\s\S]*[nN]*[\%]*[vV][\%]*[aA][\%]*[rR][\%]*[cC][\%]*[hH][\%]*[aA][\%]*[rR][\s\S]*[eE][\%]*[xX][\%]*[eE][\%]*[cC][\s\S]*" />
                    </conditions>
                    <action type="AbortRequest" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

You can change the <match url> directive above to \.as[p|px] if you want to apply the filtering rule to .asp and .aspx pages only.

Update: The SQL server security team has a more detailed blog entry on this that you can refer to.

Fixing IIS 6 issue with semi-colon

naziml — Fri, 15 Jan 2010 02:19:00 GMT

In an earlier post I talked about the semi-colon issue and since then we have published a KB article 979124 on how to configure uploads for web applications in IIS as well. To complete the story I wanted to do a quick write-up on how to go about fixing your server configuration to avoid this issue.

Step 1: Block incoming malicious requests using UrlScan

This is a stopgap solution to keep your server running while you fix the configuration issue. The simplest solution is to disallow semi-colons in your URL. Please refer to the Using UrlScan article on installing and configuring the tool. The specific piece of configuration you want to add to the urlscan.ini file is the value 0x3B in the [DenyUrlSequences] section. 0x3B is the character value for the semi-colon character.

Step 2: Identify and modify incorrectly configured upload directories

There are multiple ways that your upload directories could be misconfigured depending on how you configure isolation for your site (metabase ACLs vs. NTFS ACLs). In case you are using metabase ACLs, what we need to identify here are all the paths that have both Write and Script flags set on the AccessFlags metabase property and remove the script flag. Here’s a sample script that will find all such paths and fix them for a server. Please take a look at the output of the script to see the paths where script permissions were removed and make sure they are indeed upload paths.

' File: RemoveScriptPermissions.vbs
' Copyright Microsoft Corp. 2010
' Author: Nazim Lala
'
' This script will remove script permissions from AccessFlags for all
' paths on the local server that has both write(MD_ACCESS_WRITE) and
' script(MD_ACCESS_SCRIPT) permissions. You can optionally specify
' a remote server name to perform this operation on.
'
' Usage:
'      cscript RemoveScriptPermissions.vbs [RemoteServerName]
'
' NOTE: THIS SCRIPT IS FOR USE WITH IIS6 ONLY (WINDOWS SERVER 2003)
'
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

OPTION EXPLICIT

DIM strServer, strBindings
DIM objWebService, objWebServer, objDir

IF WScript.Arguments.Length = 1 THEN
    strServer = WScript.Arguments( 0 )
ELSE
    strServer = "localhost"
END IF

SET objWebService = GetObject( "IIS://" & strServer & "/W3SVC" )

' Enumerate websites on the server
FOR EACH objWebServer IN objWebService
    IF objWebserver.Class = "IIsWebServer" THEN
        EnumAndFixDirectories(objWebServer)
    END IF
NEXT

SUB EnumAndFixDirectories(objDir)
    DIM objSubDir

    FixScriptAndWrite(objDir)
    FOR EACH objSubDir IN objDir
        IF (objSubDir.Class = "IIsWebVirtualDir" OR _
            objSubDir.Class = "IIsWebDirectory") THEN
            EnumAndFixDirectories(objSubDir)
        END IF
    NEXT
END SUB

SUB FixScriptAndWrite(objDir)
    IF (objDir.AccessWrite = True AND objDir.AccessScript = True) THEN
        WScript.Echo "Fixing: " & objDir.AdsPath
        objDir.Put "AccessScript", False
        objDir.SetInfo
    END IF
END SUB

Step 3: Remove UrlScan filtering for semi-colons

After you have confirmed that all affected configuration has been updated, go and remove the semicolon (0x3B) from the [DenyUrlSequences] entry in urlscan.ini.

Public disclosure of IIS security issue with semi-colons in URL

naziml — Tue, 29 Dec 2009 19:19:00 GMT

IIS has been alerted to the claim of a new security issue in IIS 6 and I wanted to explain the issue and our position on it.

The issue in question affects only IIS 6 (Windows Server 2003) and arises when you send a URL with a semi-colon in it. IIS 6 uses the path before the semi-colon to determine the script handler for it. So sending a URL like http://www.fabrikam.com/uploads/foo.asp;bar.jpg results in mapping this request to the ASP script handler since it ignores everything after the semi-colon. In the case where this URL is given Execute Permissions, we will end up executing the ASP script inside a file "foo.asp;bar.jpg".

Here are the facts concerning this issue:

You MUST have write permissions to upload your content. The issue being discussed here does not let you bypass that requirement. So if you don't allow uploads, read no further, you are not exposed to the issue.
If you allow uploads of files then IIS best practices require you NOT to give script permissions to an upload folder (see bullet point 7 in the link). In the case that you follow best practices and not grant script permissions to an upload folder, there is no room for any script being executed. Requesting a URL like http://www.fabrikam.com/uploads/foo.asp;bar.jpg on a properly configured server will result in a 403 error. Hence there is no security issue on a properly configured server either.
If your server uses an non-recommended configuration and allows uploads and script execution privileges together, then only those authorized to actually upload content will be able to place said content. And in this case the existence of this issue is of no major import in letting you execute your script ... since that is exactly what you have configured your server for.

In summary, there is a functionality issue here, but there is no security issue unless you already had a poorly configured server to begin with.