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."
Just give us the exploit!
>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?
Default ASP.NET credentials are basically a signed username with an expiration date. So if an attacker can figure out your encryption, they should be able to change their identity. So user "Joe Bob" should be able to become user "Super Admin" by decrypting his cookie, editing his user id, and re-encrypting it.
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.
"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.
The first part of the presentation introduces the audience to Padding Oracle Attacks, the cryptographic concepts of the vulnerability, and finally how to exploit it. We also describe the algorithms implemented in POET (Padding Oracle Exploit Tool). POET is the free tool that we released a few months ago which can automatically find and exploit Padding Oracle vulnerabilities in web applications. The second part presents a previously unknown advanced attack. The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API! Finally we demonstrate the attacks against real world applications. We use the Padding Oracle attack to decrypt data and use CBC-R to encrypt our modifications. Then we abuse components present in every ASP.NET installation to forge authentication tickets and access applications with administration rights. The vulnerabilities exploited affect the framework used by 25% of the Internet websites.The impact of the attack depends on the applications installed on the server, from information disclosure to total system compromise.
http://ekoparty.org/juliano-rizzo-2010.php
In soviet russia the government regulates the companies.
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.
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
"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. "
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.
I don't think you're getting it.
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.
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.
upon the advice of my lawyer, i have no sig at this time
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.
Try not to be ignorant, not to say idiotic. "Any possible message" includes "any reasonable message". Come back when you understand Shannon's theorem.
Basically, the problem here is that ASP.NET leaks information about incorrectly decrypted data. If the attacker can get information about the failed decryption, then that's called an oracle. The secure way to handle any sort of decryption error is simply to say "decryption error", regardless of whether it's a padding error, a MAC (message authentication code) error, invalid plaintext, or whatever. You should never give the user the invalid decrypted data or any information about it.
Some SSL/TLS implementations have this problem, too, because they treat a MAC error differently than other decryption errors. Secure implementations, including OpenSSL, have the sane behavior: simply stating that the decryption failed.
A good way to make padding oracle attacks irrelevant is to design protocols to use cipher modes that don't require padding. In other words, instead of using CBC, use CFB. This does have some tradeoffs, but overall CFB is a good choice. (For example, OpenPGP uses CFB.)
> That person should not be called programmer.
The title is usually "Web developer", is it not?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I know exactly how a one time pad works.
No you don't, if your posts on the subject are anything to go by.
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