Totally irresponsible journalism. This is not all or .NET or even a tiny fraction. It is one control that will be rapidly patched.
This allows the end user to decrypt their own "encrypted" cookie, not an attacker. At best, if the web app writers were stupid and put truly exploitable data in the cookie, they'd be effected.
It is horrible that MS missed this, but calling .NET broken is probably actionable libel.
Reporting on this story has so far been pretty crap, and light on details; hopefully a clearer picture will develop after ekoparty. But this is a serious issue. See http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s.... The machine key can be determined if you're using AES (the default). And the machine key can be used to forge forms auth cookies.
It's not about figuring out what's in the client cookies - it's about forging cookies that the server completely trusts on account of the (broken) encryption.
Check out the quote that the authors of the paper in question note:
The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-...), although his approach seems to have relied upon default error emissions and is defeated by the common customErrors=on configuration. It doesn't sound like today's attacks have such limitations. And it isn't clear what actual effective workarounds exist, if any.
Even in cases where app logic will trip this approach up early (making hard assumptions about session vals having been initialized post-login and consequently failing fast, etc), the secrets are still captured.
Brian does not claim to have been doing it before Juliano or Thai. He wrote the blog post to explain in layman's terms what the attack was and released his own version of the original POET tool written in Perl.
Comments
Totally irresponsible journalism. This is not all or .NET or even a tiny fraction. It is one control that will be rapidly patched.
This allows the end user to decrypt their own "encrypted" cookie, not an attacker. At best, if the web app writers were stupid and put truly exploitable data in the cookie, they'd be effected.
It is horrible that MS missed this, but calling .NET broken is probably actionable libel.
Reporting on this story has so far been pretty crap, and light on details; hopefully a clearer picture will develop after ekoparty. But this is a serious issue. See http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s.... The machine key can be determined if you're using AES (the default). And the machine key can be used to forge forms auth cookies.
It's not about figuring out what's in the client cookies - it's about forging cookies that the server completely trusts on account of the (broken) encryption.
Check out the quote that the authors of the paper in question note:
The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
Plus, the researchers didn't destroy the security. It was never there in the first place. And I doubt they were the first to exploit it, either.
Exactly what evidence have you observed to make you believe that other researchers have used CBC padding oracles to break the security of ASP.NET?
Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-...), although his approach seems to have relied upon default error emissions and is defeated by the common customErrors=on configuration. It doesn't sound like today's attacks have such limitations. And it isn't clear what actual effective workarounds exist, if any.
Even in cases where app logic will trip this approach up early (making hard assumptions about session vals having been initialized post-login and consequently failing fast, etc), the secrets are still captured.
Brian does not claim to have been doing it before Juliano or Thai. He wrote the blog post to explain in layman's terms what the attack was and released his own version of the original POET tool written in Perl.