Slashdot Mirror
Researchers Demo ASP.NET Crypto Attack
Trailrunner7 writes "The crypto attack against ASP.Net Web apps has gotten a lot of attention this week, and with good reason. Microsoft on Friday night issued a security advisory about the bug, warning customers that it poses a clear danger to their sites. Also on Friday, the researchers who found the bug and implemented the attack against it released a slick video demo of the attack, clearly showing the seriousness of the problem and how simple it is to exploit with their POET tool."
There was so much wrong about that, I cannot begin to say it all. But I will say this. That "superuser" is available as a user in a web app is unforgivable. If it wasn't this exploit to take advantage of that fact, it would be another. *NIXes have learned the folly of that long ago and so now, with the exception of certain administrative tools, web services don't run as root, but as apache or some other non-root user. While this doesn't make the feat of root-level compromise impossible, it does make it less easy. (Then again, root isn't often as necessary as people seem to think as these days, the ability to run a [D]DoS or to extract sensitive information from a database only requires user level access as granted by level of the process compromised.)
Still, the dangers of a direct root level compromise is plain for all to see and understand. At that level, it's "game over" for all things including updating the BIOS or other ROM code of other on-board controllers of the host system to make "removal" or "cleaning" a much more difficult if not impossible task to perform.
I know Microsoft is not listening as we all begin to chant the same things: STOP RUNNING EVERYTHING AS ADMINISTRATOR
Maybe they will start to listen one day.
The attack requires the ASP.NET error page that shows exception information to be enabled. No sane person will leave it like this in production let alone that it is turned off by default.
I'll just let MediaWiki, Wordpress, Joomla, phpBB, and countless other site systems know that they should port to Ruby on Rails since they'll never work in the real world.
You need to keep in mind that most ASP.NET apps are developed in India. A fuck up like that is routine for them. In fact, I'd be much more surprised if they didn't screw up something as simple as that.
POET tool? More like Pwnit.
Have you ever considered piracy? You'd make a wonderful Dread Pirate Roberts.
For one, IIS does not run as Administrator, unless you for some reason change it to do that.
For two, this attack has nothing to do with that, at all. This attack basically involves a way to crack COOKIES on a client machine that are supposedly encrypted.
For three, anyone who stores sensitive data in an "encrypted user cookie" is retarded. I don't care if it is encrypted or not, rule #1 is never trust the client with anything. Quote from the article:
"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."
Why on earth anyone would put a bank balance or any other sensitive information in a cookie is totally beyond me. Also why on earth one's session cookie would be based on anything other than a totally random UUID is beyond me.
Basically this exploit takes advantage of people who poorly code ASP sites. The exact same exploit could affect a poorly coded PHP site, or poorly coded JSP site, or poorly coded CGI site.
Python is the only solution we can use in the real world. Ruby on Rails is getting close to Django, but it will never be able to catch up with Django because Ruby on Rails doesn't use Python.
Why on earth anyone would put a bank balance or any other sensitive information in a cookie is totally beyond me. Also why on earth one's session cookie would be based on anything other than a totally random UUID is beyond me.
It's beyond me too, but then I also had grave concerns about making email and documents executable code.
For four he turned the default (and secure) custom error mode setting to off.
This was demoed at the ekoparty and was pretty cool, they gave away three copies of their POET tool, the crowd was like crazy for those pen drives thrown out.
Basically this exploit takes advantage of people who poorly code ASP sites.
that would be 99% of them right?
I've talked with the 0-day authors and they said that RoR had (or have, I don't remember) the same kind of vulnerability reported in ASP.NET. The problem is that using encrypted but not signed content allows an attacker to decrypt it (check out the authors' paper for details, it is really cool).
The exact same exploit could affect a poorly coded PHP site, or poorly coded JSP site, or poorly coded CGI site.
I might be misreading the article but it appears that the exploit is specific to ASP.NET and the way they implemented AES. Unless, of course, you have some other information on how to implement this attack against the other aforementioned languages.
Per Scott Guthrie's blog, even if it's on, using anything other than a single default redirect still leaves the app vulnerable.
I may be wrong on this but I believe the multiple errors are just theoretically exploitable and practically it is impossible for an exploit to track the information needed to decrypt the cookie that way. Same goes for the timing of the error page.
I understand this is Slashdot and all, and it would be very politically incorrect to ask the editors to read the original paper about the attack, much less understand it... but, for God's sake, the paper starts with a demo of this attack on JSF (which has precisely the same issues as ASP.NET)! There's also a presentation devoted entirely to attacking JSF apps with this.
And starting from there, I'll just quote:
Besides JavaServer Faces, we have also audited someother popular web frameworks to see if they are vulnerable to padding oracle attacks. Here are some of our findings.
Since version 2.3, Ruby On Rails has introduced ActiveSupport::MessageEncryptor which is a set of functions to provide a simple way to encrypt information for storage in an untrusted location (like cookies). If you look at ActiveSupport::MessageEncryptor's source code,
you would probably see that applications that use the provided encrypt/decrypt functions would be vulnerable to padding oracle attacks.
The reason why ASP.NET is most affected by this in practice is because there are many more clueless developers who enable full exception information being passed to the client in production (and that, in turn, is largely because ASP.NET is a common tool of choice for outsourcing bids).
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
all you need is a 1-bit difference between the response for the padding error case and the non-error case.
once you have that bit you have the machine key. once you have the machine key you have all the sites on that machine that share that machine key.
no, the AES implementation is fine. the vulnerability is the ability to detect the padding exception in the block cypher.
you don't need to see the padding exception, you just need to know that it occurred. you can do that via a variety of means, not limited to http status codes, timing, etc...
NO! NO! NO!
This is wrong, and dangerous. There is no such requirement, the HTTP status code is sufficient. Actually, the timing is sufficient, but slightly harder to exploit.
This is correct, and, unfortunately, why the 1st statement is so dangerous.
Assuming that your site is safe just because you've followed best practices is WRONG! You MUST apply the fix in ScottGu's post immediately!
I for one don't care to give up all "Remember me" checkboxes on the internet.
it's not just about cookies, it's about extracting the machineKey. for 99.9% of ASP.NET sites that's a complete disaster.
if you admin ASP.NET and you think this doesn't affect you, then you're probably wrong.
You, sir, have no clue.
The interesting sensitive information ASP.NET stores in encrypted/signed cookies is the user ID.
Get the keys (which this attack lets you do), you can now make your own cookie saying you are user #1 and log in to the website as the admin.
Why does ASP.NET store the user ID in the cookie? Because you're not supposed to store a password, of course. So they encrypt and sign a user id instead.
Yes, since 99% of all sites are poorly coded then 99% of ASP sites are probably poorly coded.
Remarks about clueless .NET developers aside, there are a lot of clueless comments here.
1. This has nothing to do with exception data or stack traces being returned. It has to do with HTTP status codes. When ASP.NET is decrypting a cookie value, one of three things may happen:
A. The value is decrypted and meaningful. The application returns HTTP 200.
B. The value is decrypted but not meaningful. The application returns HTTP 200 with a human-readable error message.
C. The value is not decrypted because the padding of the ciphertext was not correct. The underlying platform throws an exception that the application does not catch. The server returns HTTP 500.
With a few thousand requests, being able to distinguish among these three cases allows you to eventually decrypt the message. That the attacker can distinguish between cases B and C is an "oracle" provided inadvertently by the platform and the way the application consumes it. The ideal solution is to make these two cases indistinguishable to the attacker. That is all we are talking about.
The advice of "never trusting the client with encrypted data" or lambasting "retarded developers" is not helpful, and, I might add, defeats the entire @#$@#$@$# purpose of encryption!
2. OK. This should sounds scary to you because you can imagine several platforms are vulnerable to this kind of attack. But of all of the platforms vulnerable to this kind of attack, in ASP.NET it is worse because once the machine key is deduced, a special request to the server using that key can be used to download any file within the application directory, such as the web.config file, which could contain sensitive information like database connection strings and passwords.
The authors of the tool also have a demo that shows the tool working against Apache MyFaces (a JSF implementation).
it's not just about cookies, it's about extracting the machineKey. for 99.9% of ASP.NET sites that's a complete disaster.
if you admin ASP.NET and you think this doesn't affect you, then you're probably wrong.
That really isn't true. It should be, if your a moron and you have incorrectly and insecurely setup your asp.net site then this may affect you. If you are said moron you should not be the admin of a site that has confidential data in the first place though. Any correctly configured site will not be vulnerable to this attack.
Microsoft acknowleged a zero day threat AND advised its' customers of the threat IN THE SAME WEEK???? Nope can't happen> Stop smokin that crack... obviously you're delusional.
"We are just a war away from Amerikastan. When god vs god the undoing of man." Dave Mustaine
That was my thought as well. Do what most Java servlet containers do, use a 256 bit securely hashed random number for the session tracking cookie. If you need to track a user for longer than an in-memory session stick that in your database as a key to the necessary info. I've always thought it rather irresponsible for storing encrypted data in cookies. You're just asking for someone to spend time trying to get your keys or session data and if they do they can spoof any data they want.
I'm not a crypto expert but it seems like generating a secure random token should be a lot easier than all that goes into implementing a functional crypto solution.
Fortran is the only solution we can use in the real world. C is getting close, but...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
also ruby on rails is vulnerable to this same attack.
This is a joke. I am joking. Joke joke joke.
Bah! The world is a dark and evil place, and we need tools that will bring with them much pain to teach those stupid developers to stay in their place! We need...Visual Basic! Even now just the thought fills the software engineers with dread, which is what you need in this cold and cruel world. Now get back to work on that VB app or I'll send your job to India, BWA HA HA HA HA!
Now get off my lawn, right after you mow it! And don't forget to trim the hedges! BWA HA HA HA HA HA!
ACs don't waste your time replying, your posts are never seen by me.
Visual basic is for weenies. QBASIC has everything a real programmer needs.
No sig today...
If you weren't encrypting data into cookies and using that to store stuff then you would not be vulnerable to this exploit, at all.
Session cookies should always be totally random. If your web app wants to "remember me" then store that random cookie in the database with the user ID affiliated. There is never any reason to store anything about the user on the client side, at all, encrypted or not.
The only reason Visual Basic has a bad rep, is that it was an horrible language when it was immature. Since Visual Basic uses the Common Language Runtime (CLR), it can do the majority of what C# can. C# is an extremely powerful language, with great frameworks and libraries. Visual Studio and the CLR, seems to have a completely different management process than windows, and has very few issues. (Microsoft.Windows != Microsoft.VisualStudio) And so what they had an stupid simple default web application that had a possible exploit if it was deployed.
The real problem is Microsoft assumed developeers wouldn't be so stupid. If IT idiots who never took a security class in there life are programming your web application, you will have problems.
Bottom line is, C# is what Java should have been if it had better backing, and VB can do the majority of what C# can. I much rather have a language that has a strong corp. backing.
I would suggest you take all your money out of any bank you use then. Two bank software vendors my company consults are frantically fixing EVERY web app on their servers due to this flaw.
Couldn't maybe a work around be: "Don't respond to 37 thousand requests in 260 seconds from an attacker?" At least not from the same IP?