Details about ASP.NET Security Vulnerability

You probably already know that there is a serious security vulnerability in ASP.NET (ver 1.0 up to 4.0). The official announcement has all the core information, here's just some overview and additional data suggesting that official workaround does not help 100%.

Vulnerability is based on the Padding Oracle Exploit. Essentially this allows to "decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API".

As claimed by the research: 60% of the time it works, every time. This happens because ASP.NET leaks security information (such leak is called oracle). Leak comes in form of indication of the error code, when attacker requests a web resources. This helps attacker steal the machine keys really fast (see video below). If error codes are not available, attacker could still measure the differences in response times.

This is the reason why the web.config workaround proposed by Microsoft does not seem to prevent the exploit 100%.

There is a really good article explaining the vulnerability. It also features another PAD exploit tool.

To make it more "fun":

• ASP.NET 3.5 SP1 and ASP.NET 4.0 secure files (like web.config or dlls) with HttpForbiddenHandler, which is protected by the machine key.
• There is a tool called POET (Padding Oracle Exploit Tool) which is public and is planned to be updated with ASP.NET Exploit.

• There is a video demonstrating process of hacking DotNetNuke (fresh installation).

Quite a few bits of information on the exploit are available in these twitter streams:

• Juliano Rizzo
• thaidn

Microsoft is working on the patch, but it is not ready yet. Meanwhile it set up a forum and proposed web.config change. They claim this to prevent the oracle.

Yet, Microsoft's temporary work-around would not help because, as Thai mentioned:

error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different

However custom error handler with random delay might help to avoid the problem.

What makes the story really dangerous:

• There is a tool to exploit the problem (ASP.NET version is promised soon).
• There are lots of script kiddies that can potentially get hold of your SQL connection string and do what they want. More serious attackers might be interested in sensitive data and contents of bin folder (or just the entire web site).
• It is saturday evening. There are no patches and the only real fix involves adding random timing delay to the custom error handler.

By the way, ASP.NET is not the only platform vulnerable to the padding oracle attack. Java Server Faces are affected (mention) just like Ruby on Rails or OWASP ESAPI (mention). The most curious part is that the last link references article published on February 5th 2010. That's more than half a year ago.

Basically there is a lot of potential damage that could be done due to the openness of the exploit, rapid information exchange in the modern world and the fact that it would take some time to fix all Asp.NET installations.

You can subscribe to the RSS feed to get new updates on this topic.

Please, warn your friends and colleagues. You can use following short links:

• This blog post with additional details: http://goo.gl/fb/yhcq8
• Announcement by ScottGu: http://j.mp/d8DV3H

Comments

[Mike Chaliy]

I do not think that your solution will help. Any detectable error response will indicate that value is invalid.

Solutions I think are:
1. Detect repetitive calls. In demo they made 38000 calls.
2. Avoid sharing any resouce that is encripted by machine key. Embded scripts, handlers, viewstate, are among them.

[Rinat Abdullin]

Mike yes. I did update the blog post after gathering more information. The only working solution seems to be adding random (large enough) delay to the error handler (you need to code it). This way it will take attacker a lot more (prohibitively more) time to get security hint for his attempt.

As for the repetitive calls - attacker could always leverage cloud or bot net to distribute the attack surface.

[Mike Chaliy]

>> The only working solution seems to be adding random (large enough) delay to the error handler (you need to code it).

1. Attacker sends request to resource. Records that it costs 500ms;
2. Attacker sends requests to brutforce and just waiting for more then 500ms, and that means error.

:)

[Rinat Abdullin]

You're right. Well, then the working solution would be to set delay to 3 seconds or more (using async sleep to prevent IIS from thread starvation). At least it will make attack much longer))

Although attacker could still do: "ok, request took more than 500ms, just consider it to be error, drop it and send another one",

[Mike Chaliy]

Well,

"ok, request took more than 500ms, just consider it to be error, drop it and send another one",

was my idea which I failed to expres :)

[Rinat Abdullin]

Then another idea would be about custom http handler that stops servicing some resource if there were more than X failed requests in last hour.

[Jonas Frost]

A wrapper IHttpHandler would work around this problem?
(And replace the *.axd and *.aspx, etc handlers with it's wrappers)

try{
delegateProcessRequest( context );
catch {
// TODO: Log exception details
throw new HttpException( 500, "Something awful happened" );
}