Researchers Demo ASP.NET Crypto Attack 98
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."
You don't know what you are talking about, at all. (Score:5, Informative)
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.
Re:Not as serious as it sounds (Score:2, Informative)
If you check out the video it shows that "custom error" messages are turned off. By turning off custom errors you are instructing ASP.NET to send the detailed error message to any connected client. The default value for this setting is "RemoteOnly" which causes the detailed error message to be sent to clients connecting over the loopback adapter and generic error messages to be sent to anyone else.
What the video shows is that the target site was configured poorly. If that is the default setting of DotNetNuke then that is absolutely a problem with that software. As mentioned, that is not the default in ASP.NET, nor is it a default when creating a new ASP.NET site in any Microsoft product.
Re:You don't know what you are talking about, at a (Score:4, Informative)
Per Scott Guthrie's blog [asp.net], even if it's on, using anything other than a single default redirect still leaves the app vulnerable.
Not just ASP.NET (Score:5, Informative)
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 [usenix.org], 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 [netifera.com] 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).
Re:This is why we need to use Ruby on Rails. (Score:1, Informative)
Re:Not just ASP.NET (Score:2, Informative)
The point still stands that, 1) the default in ASP.NET is no information about the error other than something wrong happened, so it's not exploitable; and 2) the common cause of problems in this particular case is people enabling full reporting for development/debugging, and then keeping it that way for production.
Sigh.... (Score:5, Informative)
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.
Re:Not just ASP.NET (Score:5, Informative)
ARGH! NO!
Why do you guys keep reiterating this crap.
The vulnerability DOES NOT REQUIRE the stack traces in order for it to work. Telling people that this is the case is extremely dangerous and irresponsible because it leads people to believe that they are safe WHEN THEY ARE NOT!
The exploit only needs to know that something went wrong. It doesn't need to know what went wrong. All it needs to know is that the response for a correct padding byte is different than the response for an incorrect one. The difference between a '500' and '404' in the HTTP response header is sufficient, and the 'production' error pages certainly have this difference.
Re:Sigh.... (Score:4, Informative)
WebResource.axd provides the oracle. given the oracle, ScriptResource.axd provides the local files.