7 ms·

Security researchers 'destroy' Microsoft ASP.NET security

52 points by dfj225 16y ago

deleted 16y ago
[deleted]
brettbender 16y ago
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).
- jared314 16y ago
  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.
  - tptacek 16y ago
    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"?
    - deleted 16y ago
      [deleted]
    - thinkzig 16y ago
      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-security-hack.aspx http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s...
      - tptacek 16y ago
        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.
        tptacek 16y ago
        Underlying cipher, sorry.
- ergo98 16y ago
  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.
  - mrkurt 16y ago
    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.
    - bradhe 16y ago
      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?
      - storm 16y ago
        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 http://news.ycombinator.com/item?id=1687547
      - mrkurt 16y ago
        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.
      - tptacek 16y ago
        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.
        bradhe 16y ago
- thinkzig 16y ago
  Then you should gently persuade them away from JavaServer Faces and Rails too. The same vulnerability exists in both.
  - tptacek 16y ago
    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.
    - thinkzig 16y ago
      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 http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf
      - tptacek 16y ago
        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.
pragmatic 16y ago
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?
- daeken 16y ago
  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.
  - pixelbath 16y ago
    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.
    - ars 16y ago
      So the users login token is not "sensitive user information"?
    - nopal 16y ago
      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 http://news.ycombinator.com/item?id=1687826
darwinGod 16y ago
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 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!
markgamache 16y ago
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.
- wccrawford 16y ago
  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.
  - tptacek 16y ago
    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?
    - storm 16y ago
      Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/#comment-416 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.
      - marcinw 16y ago
        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.
cryptbe 16y ago
The video is out http://www.youtube.com/watch?v=yghiC_U2RaM http://www.youtube.com/watch?v=yghiC_U2RaM

52 points by dfj225 16y ago

deleted 16y ago

[deleted]

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

jared314 16y ago
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.
- tptacek 16y ago
  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"?
  - deleted 16y ago
    [deleted]
  - thinkzig 16y ago
    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-security-hack.aspx http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s...
    - tptacek 16y ago
      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.
      - tptacek 16y ago
        Underlying cipher, sorry.
ergo98 16y ago
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.
- mrkurt 16y ago
  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.
  - bradhe 16y ago
    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?
    - storm 16y ago
      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 http://news.ycombinator.com/item?id=1687547
    - mrkurt 16y ago
      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.
    - tptacek 16y ago
      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.
      - bradhe 16y ago
thinkzig 16y ago
Then you should gently persuade them away from JavaServer Faces and Rails too. The same vulnerability exists in both.
- tptacek 16y ago
  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.
  - thinkzig 16y ago
    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 http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf
    - tptacek 16y ago
      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.

pragmatic 16y ago

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?

daeken 16y ago
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.
- pixelbath 16y ago
  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.
  - ars 16y ago
    So the users login token is not "sensitive user information"?
  - nopal 16y ago
    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 http://news.ycombinator.com/item?id=1687826

darwinGod 16y ago

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 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!

markgamache 16y ago

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.

wccrawford 16y ago
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.
- tptacek 16y ago
  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?
  - storm 16y ago
    Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/#comment-416 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.
    - marcinw 16y ago
      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.

cryptbe 16y ago

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