Frequently Asked Questions about the ASP.NET Security Vulnerability
Two days ago I published an important blog post about a security vulnerability in ASP.NET. In it I discussed a workaround that we recommend customers use to help prevent attackers from using the vulnerability against your applications.
Below are answers to some common questions people have asked since then about the vulnerability.
Important Update: You can now download the official security patch update here. Please install it ASAP on your servers – it is the only way to protect against the 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 (like the one described in this post) 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 vulnerability?
This is a vulnerability 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 vulnerability 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 vulnerability. 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 vulnerability 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 vulnerability 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.
Summary
We will post more information as our investigations continue, and we will post security advisory updates if the situation changes. You can learn more about this vulnerability from:
- Microsoft Security Advisory 2416728
- Understanding the ASP.NET Vulnerability
- My Initial Blog Post
- SharePoint Team Blog Post
- Microsoft Security Response Center Blog Post
- Microsoft Security Response Center Update Post
Please post specific questions about the vulnerability in this forum on the www.asp.net web-site.
Important Update: You can now download the official security patch update here. Please install it ASAP on your servers – it is the only way to protect against the vulnerability.
Thanks,
Scott