The ASP.Net vulnerability that was announced prior to the EkoParty conference in Argentina last week, initially sounded a lot like a whole lot smoke and not much fire. I read the summary of the exploit and belittled it in a blog post, telling people not to panic. I did however decide to review the slides of the technique used to expose the vulnerability as it all sounded rather interesting. However, I wish I hadn't as it soon came to light that the vulnerability was more serious than previously thought. Microsoft agreed and released a security advisory.
What can the attack do?
The attack is relevant to all versions and flavours of ASP.Net and is able to decrypt ViewState data, not an issue as long as you don't store sensitive info in the ViewState - which you shouldn't!
The real issue arises if using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application i.e. the web.config.
How the does it work?
The attack makes use of cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. ASP.Net acts as a padding oracle in this case. Allowing an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server (and even time taken). If the attacker makes enough requests, they can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.
Silence that Oracle!
By returning only one application error page no matter what the error effectively silences the oracle and the attacker can no longer gain the info they need to decrypt your encrypted site data. Not ideal in web apps,
Yeah actually! Any sensitive files on your server within your application should be encrypted. For example your connection strings or your username and passwords in your web.configs should be encrypted.