Tag Archives: padding oracle

ASP.NET Padding Oracle fix released, time to patch for Windows administrators

Scott Guthrie’s blog reports that a fix is now available for the Padding Oracle attack, which enables successful attackers to break the security of ASP.NET applications. There are a few points of interest.

First, there is not one patch but several, and which ones you need depend both on the version of Windows and the version of .NET. Multiple versions of .NET may be installed on a single server.

Second, the exploit is rated “important” in Microsoft security-speak, rather than “critical”. This is apparently because in itself the vulnerability merely discloses information. However, Microsoft is treating it with a high priority because the vulnerability is likely to reveal information that would let the attacker go to to more sever actions such as taking over a server. Confusing, but to my mind it is as critical as they come.

Third, Guthrie’s blog notes:

We’d like to thank Juliano Rizzo and Thai Duong, who discovered that their previous research worked against ASP.NET, for not releasing their POET tool publicly before our update was ready.

The implication is that the POET tool may be publicly available soon – so if you are responsible for an affected machine, get patching! In fact, in the webcast on the subject Microsoft stated that “The potential for exploit is very high during the next 30 days.”

Fourth, the update works by “additionally signing all data that is encrypted by ASP.NET.”

Update: Marc Brooks has investigated and it looks like there is a bit more to it than that.

Finally, the update will be included in Windows Update but not immediately. Your choice is whether to risk a hack in the period before the automatic update appears, or endure the hassle of the manual downloads. Microsoft advises to do it as soon as possible for servers on the public internet.

I am not sure what percentage of systems are likely to be patched soon, but I’d guess that plenty of vulnerable systems will remain online and that we have not heard the last of this bug.

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.