Microsoft released a Security Advisory (http://www.microsoft.com/technet/security/advisory/2416728.mspx) about a vulnerability which affects all versions of ASP.NET. This vulnerability known as Padding Oracle exploits the way an ASP.NET application handles encrypted data. ASP.NET encrypts data to prevent an application from tampering with it. Because of this vulnerability, an attacker can send data to a site and analyze the error response which provides a lot of information enabling the attacker to break the ASP.NET’s encryption in a matter of hours or minutes. An attacker then would be able to read a vulnerable application’s files and tamper with the data contained in them.

Workaround

A workaround that you can use against this vulnerability is to enable <customErrors> mode in the web.config file of your application, 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.

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:

• 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.
• 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>

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

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:

• 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.
• 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>

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

How to Verify if the Workaround is Enabled

Once you have applied the above workaround, 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 has been setup correctly. If you see a standard ASP.NET error then it is likely that you missed one of the steps above.

Microsoft is currently working on a patch to fix this vulnerability. Once released, we will apply this on all of our Windows servers. This workaround will not be needed after that.

We are looking for you to suggest what topics you would like to see on this blog. We will try our best to make sure the information that is critical to you is always available here.