ViewState, Passwords?
If you have any sensitive information within the viewstate you need dragged out and shot in the first place
Microsoft has issued a temporary fix for a cryptographic weakness in widely used web development software that allows attackers to read password files and other sensitive data. The workaround issued late Friday addresses what is known as a “cryptographic padding oracle” in ASP.Net, a series of web development programs that run …
If you think this vulnerability only exposes viewstate, you are not worried enough. The demonstrated attack gains access to ALL files including web.config and dlls which means all code and database passwords for a start.
Another common misconception is that this attack only hits mis-configured sites without custom error handling enabled. This is not correct, the work-around (which only obfuscates and does not defeat the vulnerability) involves a special configuration with only one error response page.
This is a very major risk to a very large number of websites.
PS many other frameworks have the same vulnerability in theory, but haven't (as far as I know) got working tools for the script-kiddies yet.
All it really does is slow down the attack, be it exponentially... but someone who knows the attack, and what they're looking for can still either use the http response codes, or the time it takes for the server to respond with a particular request (even if you're padding response times with a randomized delay function) to successfully pull off the exploit. Right now, it's EASY to do; Scott Gu's recommendations make it HARD to do, that's all.
Also worth noting that with this exploit you can download the web.config file of any site that's vulnerable and any file within the sitedir you know the full path to. Without a patch from microsoft, if someone wants in, they're getting in.
muzzled, not quite.
Actually, the tool uses the reply time and returned error codes together to guess the key. The workaround suggested by scottgu first redirects all errors to a single page, and then adds a delay in timing.
The delay is not necessary for this workaround to be functional. This exploit is impossible to achieve if your error page does not disclose the error data.
They very cleverly introduced a feature in .NET 3.5sp1 which allows you to download any file on the filesystem (that the asp.net process has access to) through the WebResource.axd file - http://forums.asp.net/p/1603799/4088646.aspx#4088646 - assuming you have busted the machine key
which this attack allows you to do.
This is a pretty hard fail - and I hope whichever muppet was responsible for adding this 'feature' takes a beating for making a realtivly low level information disclosure into a critical flaw.
And then I hope Microsoft disable this feature perminantly - as I.D.S.eseses are going to have a pretty damn hard time detecting this too.
I'm going to be pouring over the .NET source code this evening to try and find a way to disable this feature permanently.
.....Or I'm gonna hit the pub and mope no one cracks our sites...one or the other.
If I'd been drinking tea at the time I'd have spat it all over the keyboard when I read about database connection strings stored in the view state. Seriously, wtf? That sort of stuff doesn't go anywhere near the browser, unless I'm completely misunderstanding what you mean by "viewstate page".
In the video I the hackers are shown cracking the machine key (which I understand) but then they use this to log into DotNetNuke as a super user (which I don't). Is this because DNN does something stupid like storing an "IsAdministrator" flag in the viewstate? or is there some more general impact of this vulnerability that I haven't realised?
IIS will serve it through ScriptResource.axd. All you have to do is encrypt the arguments with the machinekey. ... the same machine key you can steal with this exploit. Ups...there goes your DB connections strings :) And if you have an shared host like most people do, you might have a sql server that is accesible from the internet (hosts do this so they allow you to connect with SQL Server Management Studio). In this case your database just got really public. All your sensitive database, and possibly admin accounts get shared with dog + world. Nice eh?