Slashdot Mirror
New Crypto Attack Affects Millions of ASP.NET Apps
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."
>If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.
This is one reason you should send user friendly error messages to your consumers instead of stack traces, stack traces can contain details that an attacker could use against you. It sounds like you're safe if you're following best practices already.
What a surprise, encryption has flaws!
RTFA. It's not about flaws in encryption. It's about "ASP.NET's implementation of AES has a bug in the way that it deals with errors when the encrypted data in a cookie has been modified"
So it's the ASP.NET AES implementation that has flaws. The problem seems to be that the errors reveal enough information about how to decrypt the data.
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?
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.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
What a surprise, encryption has flaws!
Nope, the cryptography is still flawless. ASP.NET just failed to use it correctly. AES-CBC would be perfectly secure if they used MAC to authenticate the data. MACs have been a critical part of crypto protocol design since the "DES ages" and padding oracle attacks have been known since 2002.
Just like RC4 is still secure if used properly, but WEP is broken due to protocol flaws (the problems with RC4 were known before WEP was designed).
So kids, make sure you always use MAC with your ciphers.
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.
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.
-- Let us endeavor so to live that when we pass even the undertaker shall be sorry. -- M. Twain
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.
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.)
If the geiger counter does not click, the coffee, she is not thick.
Any, no. But certainly there are many, many messages of the same length that would make sense.
To put it another way, let's say a /. sig is 120 characters (I don't know the exact number offhand) and that a million /. users have sigs, all of which are different and make some kind of sense. If I encrypt one with a one-time pad, there's no way for you, using brute force, to figure out which user's sig it is -- each of those million possibilities (and many, many more) would appear equally possible to your best discernment.
You're saying that as long as you come up with a message that looks like words and forms a sentence that's the right length, you've successfully brute forced the pad. That's not remotely the case.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager