Microsoft is warning users it has seen “limited attacks” targeting an ASP.NET vulnerability that could potentially affect many Web applications.
The issue, which was demonstrated by security researchers Juliano Rizzo and Thai Duong, is due to ASP.NET’s use of encryption padding, which provides information in error messages that can be used by an attacker to potentially read and alter encrypted data. Duong and Rizzo designed a tool to exploit the vulnerability, which they presented at the Ekoparty security conference in Buenos Aires, Argentina, last week.
“An attacker who successfully exploited this vulnerability would be able to read data, such as the View State, which was encrypted by the server,” Microsoft warned in an advisory. “This data may also be tampered with by the attacker…[who] could send this data back to the server and observe the error codes returned by the server. By observing these error codes, an attacker could gain enough information to decrypt and tamper with the encrypted data.”
“An attacker who successfully exploited this vulnerability could also read data from files on the target server, such as web.config, which the worker process identity already has access to,” Microsoft added.
Microsoft said it is working on a fix. In the meantime, enabling ASP.NET custom errors and mapping all error codes to the same error page can serve as a workaround. Instructions on how to do that are contained within the Microsoft advisory. The company’s SharePoint team warned that the issue affects SharePoint 2010 and SharePoint Foundation 2010, which require a slightly different workaround detailed here.
The publicly disclosed exploit can be used against all types of ASP.NET Applications, including both Web Forms and MVC, blogged Scott Guthrie, corporate vice president of the Microsoft Developer division. Configuring a custom 404 error page response and a default redirect for all other errors still lets an attacker distinguish between a 404 and other errors, he noted. Likewise, a custom logging module is only effective as a mitigation if the responses it sends out do not let an attacker draw a distinction between error messages through either their content or the “time that it takes to serve out.”
“It is always a best practice to encrypt sensitive configuration data within web.config files,” he added. “That way if your web.config file is ever exposed, attackers cannot use its contents maliciously.”