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."
Not so bad after all... (Score:5, Informative)
>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.
Re:Who knew! (Score:4, Informative)
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.
Re:Who knew! (Score:1, Informative)
ASP.NET uses a hashed message authentication code by default. So not sure what point you are trying to make by talking about them as a solution.
Source: see 'protection' at http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx [microsoft.com]
Follow the links (Score:3, Informative)
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 [ekoparty.org]
Re:100% reliable? (Score:4, Informative)
Basically, what I'm saying (that I don't think I expressed very clearly in my post that you replied to) is that what they're saying in the article is: If you find an ASP.NET web site (or a JSF one, for that matter) that gives back enough detail in its error messages to malformed/misized crypto packets, you can figure out what the size really should be and make it work from there, and then it'll work every time. It's like saying "A third of the time, it works every time!" Well, that's not 100%.
To put it another way, entering 'admin' and 'admin' will give you full access to 100% of machines that have a user called admin with admin privs that also set their password as admin. Or, the Blaster Worm still owns 100% of Windows 98 machines that haven't been patched in a decade. While technically true it's a useless statistic.
I have not personally encountered a site that would be useful to crack (ASP or JSF) that provides the end user with the kind of error messages they're talking about. There's no reason you couldn't, but you just never would.
More details on the "side channels" would've been nice, since the primary vector they talk about is, in practical terms, useless.
Re:Not so bad after all... (Score:4, Informative)
Re:Not so bad after all... (Score:3, Informative)
You are correct. (I think the property's called CustomErrors, but otherwise you're dead on.)
You'd have to manually decide you wanted your end users to see unfriendly error messages for the exploit as described to work. In other words, being negligent isn't sufficient for this to work -- you need to do something actively stupid.
I believe the same is true for the JSF exploit this is based on, but it's been a year or two since I've touched JSF at this point.
Re:Who knew! (Score:3, Informative)
I know exactly how a one time pad works.
No you don't, if your posts on the subject are anything to go by.
Re:Who knew! (Score:4, Informative)
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.