One comment on that page and already I want to cry: no, custom error pages do nothing to prevent this attack. Textually identical responses can be distinguished by side channel attacks, such as via timing. If you have distinct code paths depending on what kind of error you are throwing, you take different amounts of time to get through them, and even if that difference is tens of microseconds the magic of high school stats will let any computer capable of counting figure out which errors are the ones it is interested in.
I've been seeing that kind of comment everywhere this attack pops up. Or people claiming this is because ASP.NET's AES implementation has a bug in it. Or damn near anything but what's actually going on in any kind of padding oracle attack.
Comments from uninformed fanboys are to be expected. What's appalling is MS's VP in charge of ASP.NET spreading misinformation and down-playing the vulnerability.
Wow, yeah, that's pretty bad. I wonder if it's deliberate, or if they simply don't understand the attack...
The funny thing about all this is that the fix is relatively easy: encrypt-then-sign, and validate-then-decrypt. From what I gather, ASP.NET doesn't sign their data (or they decrypt (and fail early) and then validate). Implementing this may or may not break some internal code due to more data, however, so who knows when they'll push a fix.
Though, please, correct me if I'm missing something. IANA crypto expert by any means, but this attack seems conceptually simple enough that most anyone should be able to understand the causes of it if they get away from all the misinformation around it.
edit: clarification: on the validate-then-decrypt, you should be almost entirely safe, as it's bounded by the security of your signature. To make it safer yet, return the same error on a padding failure after validation as on a validation failure, and always do all steps to guard against timing attacks. Otherwise, if they get lucky enough to make a valid data block that passes your signature, they can still see / time padding errors. But that should be astronomically rare, unless you're using MD5.
You make a good point. I wonder if the time frame between writing the encrypted data, and reading it back has anything to do with it. Because if it were possible for the time frame to be long, then the application would be required to persist the signature for a while.
You lost me a bit there... writing and reading it back, and persisting the signature?
To try to cover the base I think I see: ASP.NET uses a single encryption key for all sessions, until you change the values in the web.config file (which I think requires a reboot).
I was thinking that the signature needed to be kept on the server, away from the attacker, because they could simply re-sign the message, but now I realize that checking the signature first would prevent the routine from ever getting to the decrypt algorithm, and thus no information would be leaked, so the attack would fail.
Unfortunately Microsoft is a bit between a rock and a hard place at the moment; give too little info and they'll suffer once exploits start actually occurring, give too much and create some serious panic. Then again, there's a lot of implicit info in Scott Guthrie's post, such as the increased vulnerability of pre .NET3.5 SP1 app. Some more thoughts here: http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-pad...
Cryptographically-random data + non-cryptographically-random data = non-cryptographically-random data.
In this case, the non-random data is (at the very least) where the checking code fails.
Good enough for an ASP site hosting a personal blog? Probably. Good enough for any moderate-scale target? No. Botnets break random delays pretty quickly, especially because a big attack means the server slows all operations, showing bigger and bigger differences between the two failure points.
I'd also be willing to bet that, even with custom errors turned on, at least slightly different code routes are followed between different error codes, magnifying the difference between the different errors despite displaying identically.
What I'd be interested in, if anyone knows, is if ASP.NET signs anything which is also encrypted. From what I've been reading / seeing, it seems it doesn't, and it's not just a checking-padding-first mistake. If that's the case, then ASP literally can't tell if something is valid until it hits code that tries to use it, which is a crypto-cracker's dream come true.
Using timing attacks in this case is almost not possible any actual web user would know that, do you think you can accurately analyse that the application's choice of code brunch in 35000 requests successfully? (in a multi-threaded attack)
Unless you are sitting by the server physically or it's in your localhost (even than, not for sure) timing attack simply not feasible.
You clearly do not understand the scale botnets can achieve. 35,000 won't do it, no. How about the same coming from several million IP addresses? How about millions coming from several million IP addresses?
Obviously, it is possible to break unsigned cookies. However good luck with dictionary attack protection, session-id, ssl, most banking sites are mandated to have.
From my understanding, the attack guesses the key used by the server. And in most cases the same key is used for almost everything. So they can guess it with something trivial and then use it to make a fake cookie or encrypted form element to get access. SSL and session ids have nothing to do with the padding oracle attack itself.
