Security researchers 'destroy' Microsoft ASP.NET security | Hacker News Reader

Security researchers 'destroy' Microsoft ASP.NET security

theinquirer.net

52 pointsdfj22558 comments

Can anyone provide any more solid details? This article seems to be a lot of hyperbole ("totally destroys") with little fact.

The error message provides a small tidbit of information about how ASP.NET decrypts messages. With enough of these error messages it is possible to decrypt the message in its entirety.

What message? The cookie itself?

As far as I can tell, this seems to allow you to decrypt the data within cookies. However, what would be stored within these cookies aside from a session ID? Some insight into what's actually stored in the cookie would be good, as this seems very overblown.

Honestly, if you're storing sensitive user information, or site access information in your cookies, then you deserve the resulting exploits.

I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.

So the users login token is not "sensitive user information"?

I'm inclined to disagree. Encrypted cookies should be secure, provided the underlying encryption techniques are solid.

There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others)

Am I wrong?

EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826

Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem.

Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password.

Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.

It's not like DRM. Effective DRM is impossible because the client has to have the decryption key. All you can do is try to obscure it.

This notion of encrypted cookies or tokens being an inherently bad mechanism to store information securely is a red herring. The fact is that these platforms --- .NET, JSF, Rails, Django included --- provide functionality that stores encrypted information client-side. When that functionality is broken, it's a platform-level security flaw.

Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.

It would allow you to encrypt new cookies. The default authenticated cookies for ASP.NET forms auth is a username. If you can encrypt your own username/id values into your cookie, you can effectively make ASP.NET think you're logged in as whoever you want.

It's a "padding oracle" attack, see tptacek's comment here: http://news.ycombinator.com/item?id=1687547

This is the whitepaper: http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

I believe that's an older white paper.

Discussion on Reddit: http://www.reddit.com/r/programming/comments/df72k/quite_ser...

Someone want to sum this up for me? I'm genuinely afraid to click through that link.

It's a more hostile and verbose version of the thread here.

Guess what? Reddit outdid us on this one. james_hart in particular, but also a series of smaller clarifying comments. Look at this one:

http://www.reddit.com/r/programming/comments/df72k/quite_ser...

The HN thread consists basically of knee-jerking about "those waskly sekuwity wesearchers" and blatantly overtly false statements from people who had no business giving guidance about a flaw they knew literally nothing about.

Welp, the first comment was deleted. That completely changes the apparent tone.

Alex Payne (One of Twitter's earlier employees..) had written a nice article on why he does not work in Infomartion Security, quite a while ago.

http://al3x.net/2008/12/31/why-not-infosec.html

..the core point being,about how little attention genuine, path-breaking work gets, if security researchers DO NOT make an attempt to publicise it,quite radically.

These sure are not some random guys making a bold claim.. that work has been published in Usenix!

The video is out http://www.youtube.com/watch?v=yghiC_U2RaM

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.

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.

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!

At least now the next time a client wants me to do something in .NET I have a good excuse to gently persuade them to something else (until this gets patched, at least).

Technically you change the cookie encryption method to 3DES in the server's config file to work around it. But, I would try to "gently" persuade anyway.

I can't understand why 4 people voted this comment up. The problem is with the CBC block cipher mode; it's not with AES. Who's writing recommendations that say "switching ciphers fixes the problem"?

Who's writing recommendations that say "switching ciphers fixes the problem"?

Visual Studio Magazine [1].

I've enjoyed reading all your comments on this thread. You clearly know your stuff. Based upon what you've seen so far and what you know about the ASP.NET framework, do you see any way around this short of some patch from Microsoft?

[1] - http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s...

The funny part about this story is that Thai's video (of him breaking DotNetNuke) breaks a 3DES key. The great thing about CBC padding and bitflips is that it's inherent to the block cipher mode; switch to DES-EDE, MARS, Twofish, or Serpent and you still have the same vulnerability. You don't even need to know how the algorithm is implemented! The same exploit will work, regardless of the underlying exploit.

You gotta love crypto.

Underlying cipher, sorry.

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.

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?

You apparently don't need the exception message at all. This was all discussed on the thread 3 days ago: http://news.ycombinator.com/item?id=1687547

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.

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.

Fair enough, I guess I didn't understand the attack thoroughly.

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?

>Exactly how do you know that?

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.

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?

That's a nice shtick (the defensive bit was my favourite addition). It's also facile.

They specifically detailed that it's an AES cookie encryption attack, yet you're acting like I'm going on a limb saying that?

Where did they specifically detail that it is an AES cookie encryption attack?

They didn't; this commenter has decided that he can easily infer the details of a presentation he hasn't seen from how it's reported in the trade press.

So it isn't exactly an AES Cookie Encryption Attack, it is actually worse: http://www.ekoparty.org/juliano-rizzo-2010.php

"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.

What do you mean by "local SYSTEM"?

I eagerly look forward to details on it. Where might I find them?

> What do you mean by "local SYSTEM"?

The highest system privilege level on Windows. They were able to interactively run CMD.EXE as the LocalSystem account on the remote web server.

> I eagerly look forward to details on it. Where might I find them?

The details were not disclosed until today when the attack was presented at a security conference. As far as I know there isn't anything available online yet, but that should change very soon.

I think you owe Juliano and Thai an apology. Observers can read downthread to see why.

You have their deck or their paper? URL? I'd be interested in reading the actual material.

You have it, right? You sound like you do.

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.

Then you should gently persuade them away from JavaServer Faces and Rails too. The same vulnerability exists in both.

No, Rails encrypts then signs, which means it verifies HMAC before it CBC-decrypts the message. It isn't vulnerable to this attack. What led you to say that it was?

JSF was vulnerable to this attack; Thai and Juliano, the researchers that other HN users are trashing on this thread, also found that flaw as well. I have to assume it's been fixed by now.

What led you to say that it was?

Section 5.1 of this whitepaper[1] by Rizzo and Duong, that lists Ruby on Rails as one of the web frameworks vulnerable to this attack.

Granted, this paper was published in May, and I'm not a Rails guy, so it's quite possible this has been patched as well.

[1]http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

Their comment about MessageEncryptor is accurate, but I don't believe the bare #encrypt (which could create a vulnerability if exceptions weren't laundered) is used anywhere. Rails sessions are encrypted and then HMAC'd. This pattern isn't susceptable to padding side channels.

Reply on news.ycombinator.com