Digest About Software, Entrepreneurship and AI

Microsoft has published a Security Advisory (2416728) about security vulnerability in ASP.NET on Saturday, September 18th. This vulnerability exists in all versions of ASP.NET and was publically disclosed late Friday at a security conference. Scott Guthrie has provided information on workarounds (please see Important: ASP.NET Security Vulnerability and ASP.NET Security Vulnerability) to prevent attackers from using this security hole against their ASP.NET. To help with Microsoft’s response to the new padding oracle vulnerability, a new forum was also set up: Security Vulnerability. Microsoft has now announced (Microsoft Security Bulletin MS10-070 - Important) the release of an out-of-band security update to address the ASP.NET Security Vulnerability. Applying the update addresses the ASP.NET Security Hole, and once the update is applied to your system the workarounds Scott has previously blogged about will no longer be required. But, until the update has been installed, those workarounds must be used. You can learn more about this security update release from this reading the Microsoft Security Response Center Blog Post as well as the official Advance Notification Bulletin.

ASP.NET security hole patch

Frequently asked questions

A few hours ago we released a Microsoft Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET.This vulnerability was publically disclosed late Friday at a security conference. We recommend that all customers immediately apply a workaround (described below) to prevent attackers from using this vulnerability against your ASP.NET applications.

What does the vulnerability enable?

An attacker using this vulnerability can request and download files within an ASP.NET Application like the web.config file (which often contains sensitive data). At attacker exploiting this vulnerability can also decrypt data sent to the client in an encrypted state (like ViewState data within a page).

How the Vulnerability Works

To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.NET which acts as a padding oracle. This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server. By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.

How to Workaround The Vulnerability

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page - regardless of the error encountered on the server. By mapping all error pages to a single error page, you prevent a hacker from distinguishing between the different types of errors that occur on a server. Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page. This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.

Enabling the Workaround on ASP.NET V1.0 to V3.5

If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0, or ASP.NET 3.5 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file. If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings:

<configuration>        

   <system.web>

      <customErrors mode="On" defaultRedirect="~/error.html" />

   </system.web>        

</configuration>

3) You can then add an error.html file to your application that contains an appropriate error page of your choosing (containing whatever content you like). This file will be displayed anytime an error occurs within the web application.

Notes: The important things to note above is that customErrors is set to “on”, and that all errors are handled by the defaultRedirect error page. There are not any per-status code error pages defined – which means that there are no <error> sub-elements within the <customErrors> section. This avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure.

Enabling the Workaround on ASP.NET V3.5 SP1 and ASP.NET 4.0

If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file. If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings. Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0:

<configuration>

   <system.web>

     <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />

   </system.web>

</configuration>

3) You can then add an Error.aspx to your application that contains an appropriate error page of your choosing (containing whatever content you like). This file will be displayed anytime an error occurs within the web application.

4) We recommend adding the below code to the Page_Load() server event handler within the Error.aspx file to add a random, small sleep delay. This will help to further obfuscate errors.

C# Version

Below is a C# version of an Error.aspx file that you can use, and which has a random, small sleep delay in it. You do not need to compile this into an application – you can optionally just save it into the application directory on your web-server:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
   void Page_Load() {
      byte[] delay = new byte[1];
      RandomNumberGenerator prng = new RNGCryptoServiceProvider();

      prng.GetBytes(delay);
      Thread.Sleep((int)delay[0]);
        
      IDisposable disposable = prng as IDisposable;
      if (disposable != null) { disposable.Dispose(); }
    }
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        An error occurred while processing your request.
    </div>
</body>
</html>

How to Verify if the <customErrors> section is correct

Once you have applied the above configuration, you can test to make sure the <customErrors> section is correctly configured by requesting a URL like this from your site: http://mysite.com/pagethatdoesnotexist.aspx

If you see the custom error page appear (because the file you requested doesn’t exist) then your configuration should be setup correctly. If you see a standard ASP.NET error then it is likely that you missed one of the steps above. To see more information about what might be the cause of the problem, you can try setting <customErrors mode=”remoteOnly”/> – which will enable you to see the error message if you are connecting to the site from a local browser.

Install and Enable IIS URLScan with a Custom Rule

If you do not already have the IIS URLScan module installed on your IIS web server, please download and install it:

It takes less than a minute to install on your server.

Add an Addition URL Scan Rule

Once URLScan is installed, please open and modify the UrlScan.ini file in this location:

%windir%\system32\inetsrv\urlscan\UrlScan.ini

Near the bottom of the UrlScan.ini file you’ll find a [DenyQueryStringSequences] section. Add an additional “aspxerrorpath=” entry immediately below it and then save the file:

[DenyQueryStringSequences]
aspxerrorpath=

The above entry disallows URLs that have an “aspxerrorpath=” querystring attribute from making their way to ASP.NET applications, and will instead cause the web-server to return an HTTP error. Adding this rule prevents attackers from distinguishing between the different types of errors occurring on a server – which helps block attacks using this vulnerability.

After saving this change, run “iisreset” from a command prompt (elevated as admin) for the above changes to take effect. To verify the change has been made, try accessing a URL on your site/application that has a querystring with an aspxerrorpath and verify that an HTTP error is sent back from IIS.

How to Find Vulnerable ASP.NET Applications on Your Web Server

We have published a .vbs script that you can save and run on your web-server to determine if there are ASP.NET applications installed on it that either have <customErrors> turned off, or which differentiate error messages depending on status codes. You can download the .vbs script. Simply copy/paste the script into a text file called “DetectCustomErrors.vbs” and save it to disk. Then launch a command window that is elevated as admin and run “cscript DetectCustomErrors.vbs” to run it against your local web-server. It will enumerate all of the applications within your web server and verify that the correct <customErrors> configuration has been specified.

It will flag any application where it finds that an application’s web.config file doesn’t have the <customErrors> section (in which case you need to add it), or doesn’t have it set correctly to workaround this attack (in which case you need to update it). It will print “ok” for each application web.config file it finds that is fine. This should hopefully make it easier to locate issues. Note: We have developed this detection script over the last few hours, and will be refining it further in the future. I will post an update in this section each time we make a change to it.

How to Find More Information about this Vulnerability

You can learn more about this vulnerability from:

Forum for Questions

We have setup a dedicated forum on the www.asp.net site to help answer questions about this vulnerability.

Post questions here to ask questions and get help about this vulnerability.

Is Microsoft going to release an update to fix the vulnerability?

Yes. We are working on an update to ASP.NET that we will release via Windows Update once it has been thoroughly tested and is ready for broad distribution. Until the update is available, we will also publish details on workarounds that can be applied immediately to help protect against the vulnerability. Note that the workarounds are temporary - and will not be required once the update fixes the vulnerability in the underlying products. They are intended to provide steps that you can take immediately until the update is available.

Is this an issue in ASP.NET or is it some cryptographic security hole?

This is a security hole in how ASP.NET uses cryptography in some circumstances that enables side-channel leaks through error responses. The current ASP.NET use of encryption padding provides information in error responses that can be used by a malicious party. We will be fixing this security hole in the security update.

Does this affect both ASP.NET Web Forms and ASP.NET MVC?

Yes – the publicly disclosed exploit can be used against all types of ASP.NET Applications (including both Web Forms and MVC).

Does this affect SharePoint?

Yes – the publicly disclosed exploit can also be used against SharePoint 2010. The SharePoint team recently published a blog post that describes a workaround you can apply until we release the security update.

What would an attack look like on the network or in my logs?

The publicly disclosed exploit would cause the web server to generate thousands (or more likely tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client.

You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block such clients. The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks. An attack attempt like this should also generate thousands of warnings in the application event log of your server similar to:

Event code: 3005

Event message: An unhandled exception has occurred.

Event time: 11/11/1111 11:11:11 AM

Application information:

    Application domain: c1db5830-1-129291000036654651

    Application Virtual Path: /

Exception information:

    Exception type: CryptographicException

    Exception message: Padding is invalid and cannot be removed.

Note that there are non-attack reasons to see this error as well (including cases where you have mismatched keys on a web-farm, or a search engine is following links incorrectly, etc), so its presence does not necessarily indicate an attack. The exception also does not mean that an attack was successful. Implementing the <customErrors> workaround we have provided can protect your application from the public exploit, and ensure that these exceptions do not disclose information that an attacker can use against the application.

What does the <customErrors> workaround do?

A workaround you can use to protect your application from the public exploit is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error response - regardless of the error encountered on the server. By mapping all error pages to a single error page, you can make it more difficult for an attacker using the public exploit to distinguish between the different types of errors that occur on a server. I covered how to implement the workaround in this blog post. If you are using .NET Framework version 3.5 SP1 or 4.0, the workaround provides further protection by also helping to mitigate against potential timing analysis attacks. The workaround uses the redirectMode="ResponseRewrite" option in the customErrors feature, and introduces a random delay in the error page. These approaches work together to make it more difficult for an attacker to deduce the type of error that occurred on the server by measuring the time it took to receive the error.

Can I configure a custom 404 error page response and a default redirect for all other errors?

No. By doing this you are still letting an attacker draw distinction between a 404 and other errors. Homogenizing errors is a crucial component to mitigating this attack. Note that this is a workaround until a security patch is available to fix the underlying product security hole. This workaround will not be required once we release a security update.

Am I vulnerable if I have my own custom error module?

If the responses that are sent out from your custom logging module do not let the client distinguish between error responses either through its content or time that it takes to serve out, then such a module is an adequate replacement for the customErrors workaround. These responses include both the entire HTTP response and the HTTP error code. If any of the above is not true at all times, then this is not sufficient. Instead you should send out the same error response for all errors until the security update is available to fix the underlying vulnerability.

Should I be concerned about this security hole if I don’t store any sensitive information in my viewstate?

Yes you should. There is a combination of attacks that was publicly demonstrated that can leak the contents of your web.config file, including any sensitive, unencrypted, information in the file. You should apply the workaround to block the padding oracle attack in its initial stage of the attack. The security update will fix this vulnerability.

What are best practices to secure my data within the web.config file?

It is always a best practice to encrypt sensitive configuration data within web.config files. That way if your web.config file is ever exposed, attackers can not use its contents maliciously. This MSDN documentation describes how to encrypt web.config file configuration sections: http://msdn.microsoft.com/en-us/library/zhhddkxy(VS.80).aspx. This tutorial also provides more samples of how to encrypt web.config file contents: http://www.4guysfromrolla.com/articles/021506-1.aspx

Why am I getting an error running the security hole detection .vbs script?

In my initial blog post I pointed at a .vbs script that you can run against a server to identify any applications within it that need to have their <customErrors> sections updated as a workaround against the publicly disclosed exploit.

On IIS 7, the script requires you to have the IIS 6 management compatibility feature installed to be able to use this script. To enable this, run Add/Remove Programs on workstations and Add Web Server Role Services on server operating systems and select the IIS 6.0 Management Compatibility feature under the “Internet Information Services” feature area. If this feature is already installed, please ensure that you are running the script with Administrator privileges.

Downloading the Updates

We are releasing the security update today via the Microsoft Download Center. We will also release the update via Windows Update and the Windows Server Update Service in a few days as we complete final distribution testing via these channels. Once the update is on Windows Update, you can simply run Windows Update on your computer/server and Windows Update will automatically choose the right update to download/apply based on what you have installed.

If you download the updates directly from the Microsoft Download Center, then you need to manually select and download the appropriate updates. Below is a table of all of the different update packages available via the Microsoft Download Center today. The downloads are split up by Windows Operating System (and corresponding service pack and processor architecture). Each operating system version bucket below includes a listing of all available versions of .NET that are supported on it, and includes KB and download links to the appropriate security updates.

Find your operating system within the below chart, then check to see which versions of .NET you have installed on it (details on how to determine which version of the .NET Framework is installed can be found here). Download and apply the update packages for each version of .NET that you are using on that server.

Windows Server 2008 R2 and Windows 7
.NET Framework Version	KB Article	Patch
.NET Framework 3.5.1 (Default install)	KB2416471	Download
.NET Framework 4	KB2416472	Download

Windows Server 2008 SP2, Windows Vista SP2
.NET Framework Version	KB Article	Patch
.NET Framework 2.0 SP2 (default install)	KB2416470	Download
.NET Framework 4	KB2416472	Download
.NET Framework 3.5 SP1	KB2416470, KB2416473	Download, Download*
.NET Framework 3.5	KB2416470, KB2418240	Download, Download*
.NET Framework 1.1 SP1	KB2416447	Download