Crisis for ASP.Net – how serious is the Padding Oracle attack?

Security vulnerabilities are reported constantly, but some have more impact than others. The one that came into prominence last weekend (though it had actually been revealed several months ago) strikes me as potentially high impact. Colourfully named the Padding Oracle attack, it was explained and demonstrated at the ekoparty security conference. In particular, the researchers showed how it can be used to compromise ASP.NET applications:

The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework’s API! … The impact of the attack depends on the applications installed on the server, from information disclosure to total system compromise.

This is alarming simply because of the huge number of ASP.NET applications out there. It is not only a popular framework for custom applications, but is also used by Microsoft for its own applications. If you have a SharePoint site, for example, or use Outlook Web Access, then you are running an ASP.NET application.

The report was taken seriously by Microsoft, keeping VP Scott Guthrie and his team up all night, eventually coming up with a security advisory and a workaround posted to his blog. It does not make comfortable reading, confirming that pretty much every ASP.NET installation is vulnerable. A further post confirms that SharePoint sites are affected.

It does not help that the precise way the attack works is hard to understand. It is a cryptographic attack that lets the attacker decrypt data encrypted by the server. One of the consequences, thanks to what looks like another weakness in ASP.NET, is that the attacker can then download any file on the web server, including web.config, a file which may contain security-critical data such as database connection strings with passwords, or even the credentials of a user in Active Directory. The researchers demonstrate in a YouTube video how to crack a site running the DotNetNuke content management application, gaining full administrative rights to the application and eventually a login to the server itself.

Guthrie acknowledges that the problem can only be fixed by patching ASP.NET itself. Microsoft is working on this; in the meantime his suggested workaround is to configure ASP.NET to return the same error page regardless of what the underlying error really is. The reason for this is that the vulnerability involves inspecting the error returned by ASP.NET when you submit a corrupt cookie or viewstate data.

The most conscientious ASP.NET administrators will have followed Guthrie’s recommendations, and will be hoping that they are sufficient; it is not completely clear to me whether it is. One of the things that makes me think “hmmm” is that a more sophisticated workaround, involving random time delays before an error is returned, is proposed for later versions of ASP.NET that support it. What does that suggest about the efficacy of the simpler workaround, which is a static error page?

The speed with which the ASP.NET team came up with the workaround is impressive; but it is a workaround and not a fix. It leaves me wondering what proportion of ASP.NET sites exposed to the public internet will have implemented the workaround or do so before attacks are widespread?

A characteristic of the attack is that the web server receives thousands of requests which trigger cryptographic errors. Rather than attempting to fix up ASP.NET and every instance of web.config on a server, a more robust approach might be to monitor the requests and block IP numbers that are triggering repeated errors of this kind.

More generally, what should you do if you run a security-critical web application and a flaw of this magnitude is reported? Applying recommended workarounds is one possibility, but frankly I wonder if they should simply be taken offline until more is known about how to protect against it.

One thing about which I have no idea is the extent to which hackers are already trying this attack against likely targets such as ecommerce and banking sites. Of course in principle virtually any site is an attractive target, because of the value of compromised web servers for serving spam and malware.

If you run Windows servers and have not yet investigated, I recommend that you follow the links, read the discussions on Scott Guthrie’s blog, and at least implement the suggested actions.

6 thoughts on “Crisis for ASP.Net – how serious is the Padding Oracle attack?”

  1. The crisis doesn’t affect only Asp.Net. This week the biggest brazilian host company, Locaweb, that work with cloud computing between others suffered an mass attack exploring a Linux vulnerability. Red Hat, responsible for the servers, said that the security problem was caused by a patch that was not applied. The problem? This patch is dated of 2 days after the attack.

  2. To answer your question its not serious at all. The attack depends on something basic which developers shouldn’t be failing to do in the first place. That is developers not stopping information disclosure when a error occurs. Without this the attack falls apart.

  3. Eventually any web administrator should close information about an error, that happened on server side, showing some common error page. If you show what is really going on on the server – you are potentially open for attacks, IMHO

  4. @terri, you need to start reading those links in the post. If you think everyone is so naive as to put sensitive data in the error page and that’s what this vulnerability is all about, you’re in for big surprises.
    It wouldn’t be an ASP.NET vulnerability in that case and ScottGu would not bother wasting hos time writing about it, right?
    Read up, bro. Take action.

  5. @Terry its truth that its expected to hide the error information, but that has always been about hiding all the exception details (error message, stack, etc) and what type of error occurred.

    Part of the issue is that the above is not enough. Its not usual to hide the HTTP response code related to the error. Specifically part of the initial attack showed involves responses with 404 vs. 500 HTTP error response codes.

    That’s part of the ms workaround.

  6. a more robust approach might be to monitor the requests and block IP numbers that are triggering repeated errors of this kind

    Gee, why didn’t anyone think of that before? Oh, I forgot. I did. …and I wrote a windows service that does exactly that. (More details & download including source code in my blog at )

    Unfortunately, it would appear that Juliano Rizzo (one of the people behind POET) is the only one that is even remotely cheerful about that approach…

Comments are closed.