This exploit has remarkably little applicability to the vast majority of ASP.NET applications. These guys are grossly overblowing this to try to get attention.
Exactly how do you know that? Juliano used his pre-existing tool (POET) to get admin privileges on DotNetNuke, without ever having used DNN --- or, presumably, modifying his tool. DNN is not an obscure .NET app.
What makes you make a comment like this? What evidence are you basing it on?
I have never worked on an ASP.NET-based site that relied upon cookies, encrypted or not, for anything. Even where the built-in forms authentication was used the username always had correlating server-side state that was triumphant.
So saying that you can modify cookies == a complete and utter non-issue for any site that followed any reasonable security practices.
The easy answer here is to say, "you mean besides DotNetNuke".
The deeper answer would be to point out that my day job is security evaluation for apps, roughly 50% of which are Fortune-100 web applications, roughly 60% of which are .NET applications, and you're flat-out wrong. There's a reason why cookie/session security is #3 on the OWASP top 10.
You're also presuming that the issue being discussed is, specifically, a cookie.
I understand why you're as defensive as you are; you're a professional .NET developer and Hacker News is hostile to Microsoft and, especially, .NET. Listen to me: I am not hostile to Microsoft or .NET. Microsoft is a client of ours. They do software security better than any company in the industry. Take my word for it: it appears that they screwed this one up just like everyone else that tries to encrypt with AES.
>The easy answer here is to say, "you mean besides DotNetNuke".
Yes, I see you've already mentioned DNN. It's good that you have that example. It would be interesting if I somehow claimed that every app is immune to it.
Countless apps have countless vulnerabilities.
>You're also presuming that the issue being discussed is, specifically, a cookie.
I know that the issue being discussed is specifically a cookie. It's specifically an AES-encrypted cookie.
To your edit: Defensive? Hardly. I'm just bitter after an endless stream of B.S. security claims by the security industry. It always follows the same pattern of arm waving and press releases, with a promised demonstration, and then the day of reckoning comes and...quiet. Maybe this will be the exception but, we'll see.
This has nothing to do with any sort of loyalty to .NET, though I hardly find HN to be anti-.NET, or anti-Microsoft for that matter. Whatever, in any case. It isn't my fight to wage.
"It always follows the same pattern of arm waving and press releases, with a promised demonstration, and then the day of reckoning comes and...quiet."
A few minutes ago, live on stage at a security conference in Buenos Aires (#ekoparty) they popped local SYSTEM privileges remotely on both DotNetNuke and SharePoint installed in a typical production configuration.
In case you think they stacked the deck, those applications were chosen only a couple of days ago after Juliano asked on Twitter for suggestions for the presentation.
You have their deck or their paper? URL? I'm a casual acquaintance of both Juliano and Thai, and friends with other Netifera people, and so all I have to go on is what they've told me. I'd be interested in reading the actual material.
You have it, right? You sound like you do. Otherwise, how would you know how serious the issue is?
I wonder how I might have any details about this. I mean, I'm just some random guy on the Internet just like you. Surely we must come to our convictions about things, like CBC padding attacks or web frameworks or the best internal temperature to cook meat to, the exact same way.
I think it's classy to call out two people you don't know as grandstanding opportunists based on zero knowledge of what it was they were doing and then argue with the guy who calls you out on it. I'm weird that way. I'm going to get downmodded for being a snarky asshole here, but they'll be negative karma points well worth it for my sanity.
The default "user is logged in" cookie in ASP.NET is vulnerable to this, since that cookie value is just an encrypted username. An evildoer (even a relatively unskilled one) could use this attack to login to an ASP.NET app as anyone they wanted.
To decrypt it you need an exception message...so turn on custom errors and you're protected it seems. Assuming you don't do that, once you decrypt it you get what, a session ID? Then what?
All they need is distinguishable errors when decrypts fail. The contents of the error are irrelevant. You can send a bare 500 with no content and still be trivially vulnerable to this attack.
Besides what storm said: decrypting isn't the problem, being able to encrypt a new cookie is. If I can "bradhe" as my username in my own cookie, the default ASP.NET forms auth will consider me logged in as you.
What makes you make a comment like this? What evidence are you basing it on?