Slashdot Mirror
Microsoft To Release Emergency Fix For ASP.NET Bug
Trailrunner7 writes "Microsoft on Tuesday will release an emergency out-of-band patch for the ASP.NET padding oracle attack that was disclosed earlier this month. The patch will only be available on the company's Download Center for the time being, however. The company is taking the step of releasing an emergency fix for the bug because of the seriousness of the vulnerability — which potentially affects millions of Web applications — and the fact that there are attacks ongoing against it already. The patch will fix the flaw in all versions of the .NET framework. Although Microsoft issued guidance about workarounds to defend against attacks on the ASP.NET bug shortly after it was publicly disclosed, the researchers, Juliano Rizzo and Thai Duong, said that the workarounds did not fully protect users against their attack."
First off...it's not a "decrypted cookie" - it's not that at all. The entire bug allows an attacker to download server-side information (such as web.config) which can potentially contain (and often does) information that should not be public.
Scott Guthrie wrote up a very detailed post on the vulnerability. It's fairly easy to exploit (there are videos available showing the ease in which it can be exploited), so it should be of concern to administrators and individuals writing websites/web applications running on ASP.NET.
Better link for details and workarounds:
http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
First, the ViewState is encrypted so figuring out the key allows you to inject your own data into the ViewState. The worse an app's code, the worse the exploit on this because some apps even store their "IsAdmin" flag in the ViewState and other such nonsense, so this lets you impersonate any user you like. DotNetNuke is one example of a crappy system. Worse, it allows you to upload ZIP files of themes and whatnot, so you can use this to impersonate the superuser, upload some hacks, then try to execute them. Depending on what account ASP.Net runs under and whether you are fully patched, this can lead to escalation to admin and owning the box. If you have followed all the other in-depth security practices (and for coders don't store any sensitive info in the ViewState) then this isn't nearly as big of a deal.
The big hole is that starting with 3.5 SP1 (and also in 4.0) the WebResource.axd handler takes an encrypted filename as its parameter, so you can encrypt say "web.config" and get it to happily pipe web.config to you... or any other file. It completely bypasses the normal restricted file handler. In previous releases this was not the case, the stuff it would let you download was much more limited. Granted, there are facilities to encrypt connection strings/etc in web.config, but a lot of people are lazy and just deploy with plaintext passwords and whatnot. Again, following defense in-depth practices greatly restricts the scope of any potential attack.
IMHO the WebResource.axd issue is inexcusable. There is no legitimate reason for allowing the new behavior.
Natural != (nontoxic || beneficial)
Oracle in the sense of an oracle telling you information.
The delay in the response among other things reveals the key.
the padding oracle vulnerability allows you to do two things:
1) decrypt cyphertet that has been encrypted using the site's machineKey
2) encrypt arbitrary plaintext as if you knew the machineKey
it doesn't give you the machineKey, but you can encrypt/decrypt as if you had it.
There's another vulnerability that allows you to download arbitrary files (even 'protected' ones) if you are able to encode plaintext with the site's machineKey. ScriptResource.axd is used by asp.net to compress/bundle scripts, and it takes a parameter that is encoded using the machineKey. The assumption is that the machineKey is secret, so it bypasses the regular pipeline that includes the checks for protected files. However, even though the attacker doesn't know the machine key, he is able to use the oracle to correctly encode the parameter to ScriptResource.axd, download web.config and learn further secrets.
Further, if the site encodes authentication tickets into the cookies in a predictable manner, the attacker can use the oracle to forge other valid authentication tickets. This is the attack that's shown in the video.
You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails.
the vulnerability isn't in the encryption algorithm, it's in the implementation of the CBC operation of the block cypher.
It allows you to retrieve the full key. And the key is symmetrix[sic], meaning that you can both decrypt and encrypt.
No, the oracle doesn't give you the key. The key and the encryption algorithm are irrelevant. The oracle allows you to retrieve the IV for a given cypher block, but most importantly it allows you to encrypt/decrypt without the key.
The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text. Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.
The above is mostly correct, but again, the attacker doesn't learn the key, just the IV required to generate correct padding.
This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets.
The built-in authentication methods do encrypt the ticket with the machine key. However...
If you learn the machine key then you can fake any identity.
This is not necessarily true. The identity placed in the ticket is generated by the application. If the developer chooses a predictable form of ticket, then, yes, you can generate tickets for other users. However, a developer can easily use a non-predictable ticket format to thwart this part of the attack.
As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.
They could fix this just by hiding the padding exception, and maybe adding a little random delay. It'll be interesting to see what changes they made, in 45 minutes or so...