5 ms·

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

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.

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.