Microsoft has been detected a vulnerability inside the asp.net which lead to attackers to view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config.
This vulnerability is detected in all asp.net versions and a patch has not been released fo this yet. Instead, microfoft decided to cover this security vulnerability with a precaution (workaround).
You could reach official Microsoft advisory for this issues from below link;
Also, Scott Guthrie has release 2 posts concerning this issue;
Here is also some of the FAQs concering this issue;
Quoted from Microsoft Website
What is the scope of the vulnerability?
- This is an information disclosure vulnerability. An attacker who successfully exploited this vulnerability could read data, such as the View State, which was encrypted by the server. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce useful information that could be used to try to further compromise the affected system.
This vulnerability can also be used for data tampering, which, if successfully exploited, could be used to decrypt and tamper with the data encrypted by the server.
Is this a security vulnerability that requires Microsoft to issue a security update?
- Microsoft is currently working to develop a security update to address this vulnerability. Microsoft will release the security update once it has reached an appropriate level of quality for broad distribution.
What causes this threat?
- The ASP.NET use of encryption padding provides information in error responses that can be used by an attacker to read and tamper with the encrypted data.
What might an attacker use this vulnerability to do?
- An attacker who successfully exploited this vulnerability would be able to read data, such as the View State, which was encrypted by the server. This data may also be tampered with by the attacker. If tampered with, the attacker 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.
Can I create a custom 404 page and a default redirect for all other errors to help protect against this issue?
- No. An attacker could still draw a distinction between a 404 error and other errors. Homogenizing errors is a crucial component to help protect against this attack.
Wish to be in a safe world, haa :)