Understanding the ASP.NET Vulnerability and implement the workaround

Posted by bink on September 24 2010, 3:21 AM.

Follow up on Microsoft Security Advisory 2416728 which gets limited attacks according to Microsoft. So it is realy time to implement the workaround since a patch is not out yet, probably released on Patch Tuesday in October.

The Impact of the Vulnerability

ASP.Net uses encryption to hide sensitive data and protect it from tampering by the client. However, a vulnerability in the ASP.Net encryption implementation can allow an attacker to decrypt and tamper with this data.

But what can the attacker do with this capability? Part of the answer depends on the ASP.Net application being attacked. For example, if the ASP.Net application stores sensitive information, such as passwords or database connection strings, in the ViewState object this data could be compromised. The ViewState object is encrypted and sent to the client in a hidden form variable, so it is a possible target of this attack.

If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file in the ASP.Net application which the worker process has access to will be returned to the attacker.

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 chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server.

By making many requests the attacker can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.

The Workaround - Silencing the Oracle

The workaround for this vulnerability is to use the customErrors feature of ASP.NET to configure applications to return the same error page regardless of the error encountered on the server.

By following the steps in the advisory to map all error messages to a single error page, you make it difficult for the attacker to distinguish between the different types of errors, effectively limiting access to the oracle.

How to Detect Vulnerable ASP.Net Applications

Some ASP.Net applications may already be configured to return the same error page for all server errors. To detect ASP.Net applications that are not configured this way and need to have the workaround applied to them, use the following script:

Version 3.1 Download DetectCustomErrorsDisabled.zip

Source Security and Defense blog