Microsoft has confirmed the existence of a vulnerability in ASP.Net that could allow attackers to grab potentially sensitive data residing on a target Web server or sent to a client system. Microsoft said in a security advisory Friday that is investigating the vulnerability, and the company's vice president of the .Net developer platform Scott Guthrie posted a workaround in his blog soon after.
The vulnerability, made public by security researchers Juliano Rizzo and Thai Duong, enables an attacker to snag passwords and sensitive user data. It can also give a malicious hacker the keys to the Web app on the server side such that he or she could forge authentication tickets and access applications with admin rights, thus getting at other sensitive data, such as the web.config file.
[ Also on InfoWorld.com: Researchers issue homemade patch for PDF zero-day bug | Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter.]
The vulnerability takes advantage of ASP.Net's buggy implementation of AES (Advanced Encryption Standard), specifically the way it deals with errors: When an attacker sends cipher text to the target Web server, the server sends back an error which contains clues as to how to crack the encryption. By sending enough requests to the server and studying the errors that come back, the attacker can eventually gather enough clues to decrypt the rest of the cipher text, explains Guthrie. This form of attack is known as a padding oracle and can be performed with a tool developed by Rizzo and Duong called POET (Padding Oracle Exploit Tool).
The solution, which Guthrie details at some length, 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."
The Microsoft ASP.Net website has a forum for members of the community to discuss the problem. One question posed on the forum was, "If a site was compromised and the web.config was compromised, are there any telltale signs? Assuming the black hat wasn't smart enough to remove all traces of their activity, would it show up in the IIS logs?"