September 13, 2010, 7:58AM
'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
- Español
-
Share
- (23)
Print
E-mail
41 Comments
Recommend
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.
The problem lies in the way that ASP.NET, Microsoft's popular Web framework, implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions. A common mistake is to assume that encryption protects the cookies from tampering so that if any data in the cookie is modified, the cookie will not decrypt correctly. However, there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.
"We knew ASP.NET was vulnerable to our attack several months ago, but we didn't know how serious it is until a couple of weeks ago. It turns out that the vulnerability in ASP.NET is the most critical amongst other frameworks. In short, it totally destroys ASP.NET security," said Thai Duong, who along with Juliano Rizzo, developed the attack against ASP.NET.
The pair have developed a tool specifically for use in this attack, called the Padding Oracle Exploit Tool. Their attack is an application of a technique that's been known since at least 2002, when Serge Vaudenay presented a paper on the topic at Eurocrypt.
Recommended Reads
In this case, 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. If the ciphertext has been changed, the vulnerable application will generate an error, which will give an attacker some information about the way that the application's decryption process works. More errors means more data. And looking at enough of those errors can give the attacker enough data to make the number of bytes that he needs to guess to find the encryption key small enough that it's actually possible.
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.
Rizzo and Duong did similar work earlier this year on JavaServer Faces and other Web frameworks that was presented at Black Hat Europe. They continued their research and found that ASP.NET was vulnerable to the same kind of attack. The type of attack is known as a padding oracle attack and it relies on the Web application using cipher-block chaining mode for its encryption, which many apps do.
Block ciphers need the messages they decrypt to be broken up into blocks that are some multiple of the specified block size, eight bytes for example. As messages don't always fit into neat eight-byte sizes, they often require padding to reach the specified size. 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.
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. Rizzo and Duong said that the attack is reliable 100 percent of the time on ASP.NET applications, although the time to success can vary widely. The real limiting resources in this attack are the speed of the server and the bandwidth available.
In addition, an attacker could execute this technique without waiting for the error messages by using information gained through side-channel leakages.
"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. If the attacker is lucky, then he can own any ASP.NET website in seconds. The average time for the attack to complete is 30 minutes. The longest time it ever takes is less than 50 minutes," Duong said.
ASP.NET is a hugely popular Web framework, and Rizzo and Duong estimated that 25 percent of the applications online are built using ASP.NET. However, that number is far higher in the corporate and financial services worlds, and apps such as online banking and e-commerce would obviously be prime targets for this attack.
Although crypto attacks can be quite complex, Rizzo said that this technique can be carried out by a moderately skilled attacker.
"The first stage of the attack takes a few thousand requests, but once it succeeds and the attacker gets the secret keys, it's totally stealthy.The cryptographic knowledge required is very basic," Rizzo said.
Shorten URL: 
. Click to copy to clipboard or post to Twitter
. Click to copy to clipboard or post to TwitterKaspersky Lab Channel and Alliance Partners
Today's Most Popular
- Rob Cheyne on Security Education and the Problem of People in Security
- 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
- On the Evil Maid USB Attack, Time Warner and the Cybersecurity Czar
- Paul Judge and David Maynor on Twitter Crime and Searching for Malware
- U.S. Reigns As Most Bot-Infected Country
Newsletter Sign-up
Newsletter Sign-up
Security news and analysis with expert opinion and perspective from the Threatpost editors.
Take Our Poll
Threatpost Content as You Like It
 |
 |
 |
 |
| iPhone App | Newsletter |
Comments
What precisely will this do other than reveal the length of the key, modulo whatever the block size is? You'd need to brute force search within the designated key size range in order to find the key, and you'd still then need to do it within the lifetime of a persons session.
I'm not sure what exactly they've achieved here?
Explain "side-channel leakages"?
The POET tool doesn't appear to understand cookies, so how would it be able to attack forms auth?
I'm glad that POET doesn't understand cookies! Hope it is not easy to implement.
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.
The title of the article seems very misleading, and a bit sensationalized.
If this attack relies on error messages being returned to the client, then it hardly affects millions of ASP.NET apps. All applications when deployed should have verbose error turned off... this is standard deployment practices. If someone forgets to do this and the app is returning error details to clients, they have a big problem regardless.
That was my first thought too, but I think you are incorrect. All it would need to know is that the request failed in some way. That could mean the server takes longer to respond, the username isn't set on the response, or something out of the ordinary occurs.
First off, this only works if the developer is dumb enough to stuff crap in cookies. Generally, you should only use cookies for the session state, if that. Everything in the session state should be stored in a database (or other persistent media) on the server side. Didn't we have this discussion regarding viewstate some years back? Same thing... Store it on the server side. At best, they can retrieve your viewstate or session state ID which is pretty much invalidated on the next page request. Also, make you sure bind those session/viewstate decoding calls to at least the subnet to make sure you don't get some hacker out there hijack a session. I know, even thats not perfect but it's better than nothing at all.
This seems more plausible on an Intranet application where the company thinks "inside = secure" and does not use HTTPS for the entire transaction internally. Maybe HTTPS is just used for logging in. There are a lot of those applications.
Yes I could see where this would be an issue.. That is of course if you ignore the fact that if you can view a cookie of an active session, decrypting the contents is pretty meaningless.
An infinite downvote for the lack of a real security threat. This article should be title 'Things you should probably already know about transfer protocols' or 'The internet; a big scary place!!11!1!'
The biggest application would be getting round the CAPTCHA protected sign up forms as these are vulnerable to this attack as they will decrypt any ERC thrown at them and the p0 (target text in this case) is designed to be human readable.
(First commenter, returning again)
Glad to see everyone else is sharing in the conclusion - no security threat of note, unless an application is putting sensitive information in a cookie and trusting it blindly. I've not stumbled onto an application that sets 'IsAdmin=true' in a cookie for some time.
Gotta admit, the sensationalist bullshit had me going for a minute, but I'll be ignoring this site going forward. Infinite downvote for editorial quality.
clearly this author has some personal motive against .net (possibly a php/java/etc freelancer hoping to use this to convert some prospective clients from their existing .net sites via fear mongering of the laymens?) to have written such a biased article.
serious downvote x 1000
An example of side channel is measuring the length of time it takes for the application to reply with an username and password error.
I think before you judge, you should wait until the research is presented at Ekoparty and ignore all the speculation until then. It's the present ignorant speculation that increases the value of the research. The foundation of message integrity and authentication presently resides in cryptography, hence their statement when it breaks, it breaks badly.
Clearly the majority of posters saying this is a useless article haven't bothered to RTFWP. Which celarly states that the attack can break WEP WTLS, SSH, SSH2, IPSEC, etc encryption to get at the data. It also states that at least some of these protocols can be configured in such a way as to defeat the attck. But that configuration is not necessarily the default or common one. So, this is a real threat. Whether any online banks are vulnerable remains to be seen. I would not be surprised to see small local banks susceptible.
The FormsAuthenticationToken is serialized and stored in the forms auth cookie. So if you are able to manipulate that cookie you could change the forms auth token name in the cookie to "admin" and become the admin.
@asmx86: All banks in the world do NOT use SSL (TLS) for all HTTP requests. They typically use it only to protect the login page (and often only the POST to it!). As for what applications put in the cookie's cleartext: the only thing that helps is to have large, unpredictable session IDs as the cookie cleartext, because predictable cookie cleartext allows the attacker to re-create valid cookies with ease.
The problem is not doing integrity protection correctly. "Crypto is hard" -- I want a Barbie doll that says that.
Yes but if the coaxial probability of peek (-16336) is infinite then the flux capacitor is fatally flawed. It would make more sence to run fibre optic cable and cross over to a speaker wire splitter box.
Nico, if there is a bank that does not use HTTPS for all the logged in part I'd be very scared to be a customer of that bank. I doubt there is a single bank that does not use HTTPS for everything.
If the login only is HTTPS and the rest is HTTP you can very quickly sniff the session, steal the cookies and start transacting on that user's behalf in less than 1 minute. And that has nothing to do with cookie encryption or ASP.Net. Any site not using HTTPS is vulnerable for cooking stealing. You don't even have to decrypt it, you can just use it in 99% of the scenario.
Show me one single bank without HTTPS and I'll be rich, sun-bathing happily in Fiji within 24h.
Corneliu.
Nico, most of the banks are using SSL for the whole online banking application. Please point out one bank in which doesn't use SSL for their whole online banking site. This article is a misleading one. What they could do is just to be able to decrypt/modify the cookies which are protected by .NET framework. If stupid enough .NET developers store critical/sensitive information in their applications then it would be a problem, otherwise, it's almost useless.
"own any ASP.NET website in seconds" statement is an over-hype and lame statement.
Everyone who waves this one off is not really getting it. ;-P
And isn't paying enough attention to the way typical ASP sites store state, authentication, credentials and other important material.
But I'm sure you'll figure it out once your, or an important site to you gets popped because of it.
The article also should mention that the mitigation for this "not quite so lame" vulnerability is enabling HMAC view states.
cheers,
--dr
P.S. This is the kind of crypto procedural bug that will have "ripple" in other implementation and places that use the MachineKey code. Waiting for the re-runs in syndication. ;-P ;-)
Why they do not used HMAC for signing encrypted cookie first, to know that they are decrypting valid something?
The article fails to mention Microsoft Corp.'s statement/opinion about the issue, and such one-sided presentation is a serious breach of basic jornalism ethics. Shame on Dennis Fisher!
See
http://en.wikipedia.org/wiki/Side_channel_attack for a good definition of a "side-channel attack" which is essentially the same thing. A side-channel "leakage" would be just a more passive attack.Regarding the question about POET not being able to understand cookies, so how
would it be able to attack forms auth...
Based on what I've read here and elsewhere, I suspect that the encrypted ASP.NET __VIEWSTATE is also likely to be susceptible to a padding oracle attack. (However, that's just speculation on my point at the moment.) But the __VIEWSTATEis often passed as a "hidden" form parameter and I've frequently seen it used to support authentication and/or authorization in which case POET could likely address that without any changes. Besides, I doubt that it would take that much work to get POET so that it could operate on cookies anyway.
"First off, this only works if the developer is dumb enough to stuff crap in cookies."
If you look back that the 'information exposure' or cross site scripting scandals of banking sites over the last few years, ASP.Net is in the mix. ASP does seem to have more than its fair share of developers, who know little about security, relying on frameworks and 'generation tools' from Redmond.
True. When I use forms auth, I handle all of the authentication myself and I put in a random wait state when the password/username isn't valid. It's not a perfect path but it also slows down manual guessing.
True. I've been a .Net developer for a long time (and you're quoting my response). My background included many years in the financial sector where security trumped everything else. I guess that gives me a little more experience in writing secure applications than the average person who picked up the "crash your IIS app in 24 hours" book.
I think that's also one of the things that employers simply don't understand anymore. any moron can code .Net/Java/PHP/Python, but you really need to find and keep those that have the experience to not shoot the company in the foot when it comes to lack of things like security.
Post new comment