New Crypto Attack Affects Millions of ASP.NET Apps 156
Trailrunner7 writes "A pair of security researchers have implemented an attack that exploits the way that ASP.NET Web applications handle encrypted session cookies, a weakness that could enable an attacker to hijack users' online banking sessions and cause other severe problems in vulnerable applications. Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications."
Re:Who knew! (Score:4, Insightful)
This is /. aren't you supposed to say "What a surprise, .NET has flaws!" ?
No, no, no ... you're supposed to say "this doesn't affect Linux". But does it affect Mono?
Re:when it comes to anything important: (Score:5, Insightful)
roll your own at the lowest possible layer. anything else and you're leaving your chin open.
I don't know about that. I'm not out to write my own implementation of OpenSSL anytime soon. Some tasks are simply best left to field experts.
100% reliable? (Score:5, Insightful)
TFA has a bizarre idea of a "100% reliable" attack:
"It's worth noting that the attack is 100% reliable, i.e. one can be sure that once they run the attack, they can exploit the target. It's just a matter of time."
By that logic, this attack is 100% reliable against (web platform of your choice) too.
Beyond that, this attack requires fairly verbose error messages be sent back to the user of a web application. While I'm sure there do exist some ASP sites where this is the case, I don't think it has been in any of the non-intranet sites I've seen in my career.
It just is not standard in any exposed web site, especially the kind of web site where you would care about customer information getting out, to allow useful error messages reach the end user. It is by far the standard to catch the exceptions, log them on the server, and show the end user a generic error message which would not be helpful in the case of this exploit.
Meh... (Score:2, Insightful)
"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. The attacker may also be able to create authentication tickets for a vulnerable Web app and abuse other processes that use the application's crypto API."
Anyone storing these things in a cookie, regardless of encryption, needs to step away from the keyboard and stop developing web applications.
This is a non-issue as long as you realize that what is encrypted can be decrypted and keeping that in mind when you store information in a cookie.
Re:when it comes to anything important: (Score:1, Insightful)
I originally modded you funny, but I'd like to retract and mod you "scary".
Now you could implement HMAC using other OpenSSL primitives, and that would be less than the highest possible level. But you WOULDN'T DO THAT!
When it comes to crypto, use the highest possible layer. I've never used ASP, and i'm rather glad, but before now I would have guessed it exposed encryption libraries to allow you to send a session cookie over HTTPS/HTTP only.
Re:Who knew! (Score:2, Insightful)
I'm going to be a crypto pedant here for a moment. Don't use the words "perfectly secure" to refer to any cryptographic scheme other than a true one-time pad. The phrase "perfect security" has a *very* specific meaning in cryptology, defined by C. E. Shannon, and the only thing that meets the definition is a true one-time pad (a symmetric key that is perfectly random - the odds of any particular bit in the string being 1 are exactly 50% - and longer than the message it encrypts and is only used for that one message).
AES is extremely secure (no one who publishes has found a practical attack against it that's easier than brute force, and all the best cryptanalysis folks who publish have been trying since the original submission of Rijndael for the AES contest), but it cannot be "perfect" - because a brute force attack will work. Even a brute force attack won't work against a one-time pad.
Re:when it comes to anything important: (Score:4, Insightful)
If you know enough about cryptography to make a good implementation, then your job does not involve writing web applications.
Very true, but there's no point in feeding trolls, they never get full.
That's some dumb stuff to be storing in cookies... (Score:2, Insightful)
Re:Who knew! (Score:5, Insightful)
Respectfully, are you sure you understand how a one-time pad works?
Attempting to brute force a one-time pad is as likely to produce a third option:
3) The account numbers to the secret Swiss Bank account are 3435464482 and 363578345. Please do not access the accounts more than once a month.
as your #1. In other words, the same message with totally different account numbers. Or any other message of the same length.
Re:Who knew! (Score:2, Insightful)
Brute forcing a one time pad makes "The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month." just as likely as "The account numbers to the secret Swiss Bank account are 123456789 and 987654321. Please do not access the accounts more than once a month." and you have no way of telling which one was the original message.
Re:Who knew! (Score:3, Insightful)
if the original was normal human readable text it becomes immediately obvious when your brute force succeeds
You will get any possible message of the same length, including several normal human readable ones. Barring having other information, there isn't any way to determine which one is the actual message. For example, if you have a 28 character message, attempting to brute force the OTP it will give you both of the results below, both equally plausible, along with many others which are equally plausible.
meeting canceled, stay home.
meeting at 10:00, room 1103.
Re:Who knew! (Score:1, Insightful)
I don't think you know how a one time pad works - trying to brute force a one time pad will yield both "The account numbers to the secret swiss bank account are 12345 and 67890" and "The killer is staying in the Slashdot hotel, room number 1235", along with literally every permutation of letters and numbers (or whatever you're encrypting) that can be possibly produced. The only attacks against OTP are side attacks, against things such as your random number generator and transmission of the key.
Re:Who knew! (Score:5, Insightful)
Even one time pads are susceptible to brute force attacks.
Nope, absolutely incorrect. That's what makes one-time pads different. When the key length is the same as the plaintext length, it is possible have perfect security. Look up unicity distance.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
But your brute force attack will yield every single possible plaintext (with the same length as the original plaintext). Which is the real one?
For example, if the ciphertext is BWIJAA, your brute force attack will get ATTACK for one key, and GOHOME for another. (And every other 6 character string.)
Re:Who knew! (Score:2, Insightful)
Re:Who knew! (Score:3, Insightful)
Actually the implementation and use of AES in the ASP.NET framework is fine.
Websites that aren't trapping internal exceptions are bugged.
The problem here is the developer using the code who isn't catching the exception, and worse still allows it to pass through directly to an untrusted 3rd party (the user).
Its not an ASP.NET bug if you proceed to print the password on the screen when users attempt to login, this really isn't any different. The dev using the ASP.NET framework is using it wrong.
Re:Not so bad after all... (Score:1, Insightful)
There is no reason for an application to do that. ASP.NET already does that by default. If an exception occurs the user is presented with a friendly error message that basically says, "something went wrong, try again later." The full error message is written into the logs on the server and can be reviewed by an admin. Said admin can also browse to the site via localhost to get the full error message as it occurs, something remote users will not see.
This "exploit" relies on the "bank" deploying the site to store sensitive information in cookies that are handed off to the browser and for the admin to have changed the settings to pass full exception information to remote users. If you know a financial institution that does either, let alone both, avoid doing business with them or anyone they might be associated with at all costs.
Re:Not so bad after all... (Score:1, Insightful)
Just to expand a litle:
"See if there is any error message. Even a blank page is enough information."
Makes me think that this may be an issue after all