Saturday, September 18, 2010

If you are running, hosting, using, admin’ing, etc ASP.Net (any version) you need to know about this new security vulnerability, how it can expose the all files the Worker Process can access and how to work around it.

[Update, 9/29/2010]
An out-of-band patch has been released to resolve this issue. It should be available via Windows/Microsoft Update or you can get it from here, Microsoft Security Bulletin MS10-070 - Important. If you, apply this patch ASAP…

Security Research & Defense - Understanding the ASP.NET Vulnerability

“Our recent advisory describes an ASP.NET vulnerability which was recently publicly disclosed. This blog post will give you more information about the vulnerability and the workaround. It will also provide a script which will help you detect ASP.NET applications on your server that are in a vulnerable configuration.

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. [GD:Emphasis added]

How the Vulnerability Works

To understand how this vulnerability works, you need to know about cryptographic oracles…

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:

technet…”

ScottGu's Blog - Important: ASP.NET Security Vulnerability

“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…

…”

You all have probably heard about this already, but just in case not… Given the possible impact and scope I thought I’d help try to get the word out…

No comments: