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."
What a surprise, encryption has flaws!
I never could find how session ids were generated, suffice to say I didn't trust MS to implement them properly.
I ended up rolling my own session management in "old asp" using a COM wrapper to crypto api for access to the RNG + hashing functions, and allowed for a SQL backend, so we could run load-balanced servers and still have a session. I would do an application-key hmac on the output of the RNG (which I also didn't trust), concatenated with a knowable, sequential, unique part.
I don't use ASP anymore.
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.
roll your own at the lowest possible layer. anything else and you're leaving your chin open.
When will MS release a patch for this? This could be really, really bad. I think it still requires that an attacker capture a cookie in order to steal the session, but not totally sure about that?
Anyone know just how serious this is?
Will more of the script kiddie hacking packages have "hardcore" venomous snake related names and graphics(ASCII for the l33t) or "hilarious" anal violation pun derived ones?
Recently I reviewed code of a colleague.
"Q: Why does the app store authorization i cookies?"
"A: But it's encrypted!"
Only a idiot would store "important stuff" in cookies. It's only a matter of time to break it.
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.
Crapware, Inc..
Yours In Vladivostok,
K. Trout
Seems to be more of a problem with the web application and less of ASP.NET. I mean, sure you can get the encryption key to the cookies, but seriously who puts information like a bank balance or a social security number in a cookie anyway? You should have that stored server-side and only use a session id.
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.
And all the paid MS astroturfing fanbois started singing in choir the monocrop argument. Uh, no... Wait : .net is not the most successful platform for webapp. Darn. The monocrop fallacy ain't working this time, need to find another fallacy.
I don't generally bother storing anything in a cookie if I can avoid it. There are simply better ways to do things IMHO.
On the other hand, if this will allow someone to spoof an asp.net user session (rather than a roll your own authentication system) then I may be in trouble.
Of course if it needs a verbose error in order to work, I'm fine. FriendlyError.aspx doesn't show stack traces.
I immediately thought, "how would you even snip some one else's cookie in the first place"? Unless the site was not using SSL and you sniffed it off an open WiFi connection. Maybe this is what they meant by "side channels".
Copied this comment from "asmx86" on the TFA's talkback comments:
Totally useless. If you can sniff in realtime then you can already hijack their session which means accessing the site with user's credential.
So, what they discovered is that you can crack the content of this and see whats in it - which means the application itself must SAVE in these cookies important data, maybe stupid programmers do that - the way to do it is just using the session id and save data server side.
Besides all this, all banks in the world use SSL - try to break that...
Anyway, good research but too much smoke if you know what I mean.
Cmon!
1) HTTP over SSL - sniff and BREAK that.
2) Important information in the cookies? That person should not be called programmer.
So maybe, MAYBE.. you could apply this to i-want-to-make-this-conference-very-popular-selling-some-smoke-yay.com.ar - thats it.
Whats the big deal here? Good research, sure.. too much SMOKE to publicity some mid-lame conference (Mid basically, there is some very intelligent people at it, wonder why...)
"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. "
So kids, make sure you always use MAC with your ciphers.
There are actually a couple of things that people should probably generally know:
http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
http://rdist.root.org/2010/09/10/another-reason-to-mac-ciphertext-not-plaintext/
And as for MACs: don't try to roll your own, but use HMAC. Doing a simple (m = plaintext, k = key) solution as on of the following
H(k || m)
H(m || k)
is not secure even though many people think they are "salting" things with a key of some kind:
http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/
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.)
Another way is to look for known source code keywords. You can start by looking for code that imports low level cryptography libraries such as:
.NET: .NET Cryptography, Microsoft CryptoAPI
C/C++: OpenSSL, Crypto++
Python: PyCrypto, M2Crypto
Java: Java Crypto Extension, BouncyCastle
Then look for routines that perform encryption and decryption. If there’s some code to handle error while decrypting, and/or no sign of MAC usage, then it’s high probability you have found a target for the Padding Oracle attack. Regardless of which method one uses, the most important thing is to analyse and understand the meaning of error messages returned by the target upon receiving mangled ciphertexts. In short, you need to know when the padding is VALID, and when it’s INVALID.
You do realize that there's no exploitable pattern in a proper OTP, yes?
This means that for a sufficiently long OTP encrypted text, both your comment and my comment look like "valid" decryptions. As are bomb making instructions, the menu for Obama's dinner last night, whatever your password to /. is, and the combination to your bank's vault.
I forget what 8 was for.
As we've seen with Windows etc, stick with just as good off the beat frameworks.
MAC = Message Authentication Code, prevents a client from forging a valid value. You can think of it like a digital signature, except that it’s much faster and the same key creates and verifies the data - which is perfect when your web app generates, sends the value to the client, receives the value from the client, and wants to verify that it is the same thing it sent originally (i.e. hasn't been changed/forged).
Given an oracle, this vuln does make decrypting a token – and thus getting the plaintext – O(n), instead of O(2^n) as brute force would dictate. It doesn’t require plaintext, just a ciphertext, and the attack finds the plaintext a byte at a time, from the end. From skimming it, it seems their paper doesn’t actually describe the attack (see below), but rather just describes how to test for the presence of the vulnerability.
Anyway, the oracle condition typically occurs when you hand something to the client and check it later, which is really a sign you should be using MAC (specifically HMAC). You can also use encryption if you want to hide the value, but for random nonces and session IDs, it doesn’t usually matter (doesn’t hurt, either). You’ll want to encrypt-then-MAC if you do both.
Background knowledge necessary for the attack:
PKCS#5 padding is: If your input is a multiple of the block length, add a full block of padding. Otherwise, add enough octets to pad to a block length. Each octet of the pad always has the number of octets of padding used. So for example, the plaintext ALWAYS ends in 01, or 02 02, or 03 03 03, etc.
In CBC mode: flipping bits in the previous ciphertext block flips the same bits in the next plaintext block after decryption. See my paper[1] for a pretty picture.
Attack
Suppose your plaintext ends in 04 04 04 04. If I twiddle the last octet of the (previous block of) ciphertext, only one value will give valid padding in the plaintext – 01. Now I fix the last octet to 02 (by flipping the two least significant bits), and go to work on the previous octet, trying to make the plaintext end in 02 02.
As a side effect, if I know what bits I had to flip to get the valid padding values, I know that your plaintext differs from the valid padding value in exactly those bits. But the real problem is that the only thing between me and a valid plaintext is this padding (and the vagaries of your block cipher mode). It's like using a screwdriver when you should be using a hammer. You'll see this over and over again in crypto; "use things for what they are designed", or "only rely on the actual security guarantees of your primitives".
Extra credit:
[1] http://www.subspacefield.org/security/web_20_crypto/ - the premise of which could have been "you probably want to use MAC, not encryption"
[2] http://www.subspacefield.org/security/security_concepts.html - for crypto-related reading (I'll put this description in there shortly)
I have no problem with the fact that these guys found the exploit or that they disclosed the exploit publically. My problem on this is that they disclosed it publically before disclosing it to the vendor. the result is a potential 0 day attack. Now potentially million of man hours will be wasted because this weekend and during this coming week all around the world. As I understand it, this sxploit effects many different platforms, not just asp.net. These guys were wreckless. , unfortunately, some people will cheer them on and think that this is good