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."
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.
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.
Per Scott Guthrie's blog, even if it's on, using anything other than a single default redirect still leaves the app vulnerable.
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).
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!
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.
You should check out this article that was on the front page a couple hours ago. http://linux.slashdot.org/story/10/09/18/2325240/Hole-In-Linux-Kernel-Provides-Root-Rights
-]Phreak Out[-