Update: Earlier this evening Microsoft updated its Security Advisory to report its awareness of “limited attacks” against this vulnerability. The update did not go into details.
Also, the Security Advisory was updated with more FAQ information and clairfication to the workaround section.
Microsoft is investigating the vulnerability found in every version of ASP.NET, which was demonstrated live last week during the Ekoparty Security Conference in Buenos Aires city. While working on an official fix, Microsoft has some mitigations for the problem, but those can come with a cost.
During Ekoparty, researchers Juliano Rizzo and Thai Duong used POET (Padding Oracle Exploit Tool), which was first demonstrated at Black Hat Europe and released to the public earlier this summer, to exploit vulnerabilities in ASP.NET-driven Web applications.
The demonstration preview used by the conference materials said the researchers would run live attacks against “components present in every ASP.NET installation to forge authentication tickets and access applications with administration rights.”
The overall impact of an attack, according to the researchers, depends on the applications installed on the server, so it could range from information disclosure to total system compromise.
“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,” Microsoft’s Scott Guthrie explained in a blog post over the weekend.
In this case, the padding oracle attack - known to the cryptographic community as a whole since 2002 - hijacks ASP.NET sessions by padding the encrypted data on ASP.NET's session cookies. This triggers an error message that provides enough information on the way ASP.NET decrypts messages to make it possible to decrypt all the data.
Security vendor Art of Defence said that an attacker could expose passwords, banking information, social security numbers and everything else encrypted using the framework's API.
According to Guthrie, one workaround 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.”
“One of the ways this attack works is that it looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests),” said Guthrie.
“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,” he added.
In response to the fix itself, Thai Duong said the error message setting is irrelevant.
“No error? There’s always HTTP status. Always the same HTTP status? There’s always big timing different.”
The problem with this fix, based on the stance taken by many IT administrators, is that reverting to a single error page, no matter the actual application error, could result in poor user experience. In addition, there could be unforeseen application issues and the loss of customizations, which could impact business performance.
As one comment pointed out on Guthrie’s blog, the problem “...is in the AES encryption algorithm, which allows cracking the cipher by using oracles. The only real cure is not to store any sensitive data on the client.”
Microsoft is working on a fix, but there is no information as to when it will be released.
In the meantime, ASP guru David L. Penton has published some additional information that rounds out the fixes suggested by Microsoft. You can see them here.
Microsoft’s Security Advisory can be viewed by clicking here.
More information on POET can be found here.
The video below is a demonstration of an attack using the ASP.NET vulnerabilities against DotNetNuke. The result was access to the SuperUser account, and shell access to the server.
[Note: Watch this with the sound off if you are at work.]