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.