New Crypto Attack Affects Millions of ASP.NET Apps 156
Posted
by
CmdrTaco
from the duck-and-cover dept.
from the duck-and-cover dept.
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:5, Interesting)
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.
Re:Patch? (Score:2, Interesting)
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.
Re:100% reliable? (Score:3, Interesting)
100% seemed wrong to me - there seems like a lot of ways to secure against the attack based on the article, but that article seems unreliable in the details as you point out. This attack does seem to require some kind of non-generic output from the ASP server side:
The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.
But what's really not clear is their reference to "side channels" where this information might also be obtained. Perhaps they can gain some understand of the errors from the time it takes the process to return to the query or other metrics?
In terms of speed - they claim they haven't run across a .NET implementation that they couldn't break in 50 minutes (avg 30 min). So this isn't an arbitrary N-time exploit - this is pretty concrete.
Re:Follow the links (Score:3, Interesting)
Thanks. It also got me thinking that if all this transactional stuff affected by POA is secured in an SSL channel, then it would be hard to get at it to begin with? This attack seems predicated on getting a hold of other's encrypted cookies/password in order to be powerful? This is just a sophisticated man-in-the-middle attack with capability to unwind *one* encryption channel? If SSL is in operation, then this doesn't help?
They claim it would work against many bank sites, but it seems like all bank sites use SSL.
What am I missing?
Oracles are not new (Score:2, Interesting)
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.)