asp.net oracle padding flaw – question?

By now many of you have heard of the ASP.NET Oracle Padding Flaw. There’s a number of posted workarounds, and MS will be issuing a patch soon to fix things.

From threatpost.com:

The problem lies in the way that ASP.NET, Microsoft’s popular Web framework, implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions. A common mistake is to assume that encryption protects the cookies from tampering so that if any data in the cookie is modified, the cookie will not decrypt correctly. However, there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.

The issue here seems to be that there’s *anything* of value stored in the cookie beyond a generic token.  This really does seem to be the case though.  Watching the DNN exploit, it looks like the fact that someone is a superuser is encoded in the cookie value itself.  This would seem to be an architectural flaw in DNN, but I get the feeling that most ASP.NET apps were/are trusting of the encyrption mechanism to hide whatever data they’re sending down in cookies.  This seems to be a more fundamental flaw in design than any AES algorithm MS may have had an issue with.

I’m reminded of a company I worked for years ago which kept track of sessions by incrementing a counter in a DB, grabbing that counter, encrypting it, then using that value as the value in the cookie.  This was thought of as ‘secure’ because encryption was being used.  I tried to argue for random values as the cookie token, but was told that ‘random isn’t really random’.  I pointed out that dozens of people (who no longer worked there) had access to the encryption key, and once I knew how to decrypt one token – which would give me a value, of, say 4554678, changing the value to 4554672 then reencrypting would be trivial and allow me to impersonate other users on the system.  My concerns were dismissed because I wasn’t a ‘senior’ engineer, apparently I didn’t understand Java or cryptography enough to understand their level of sophistication.  After all, ‘random isn’t really random’.

This approach of putting sensitive data in a cookie, then encrypting it, seems to be alive and well, and that scares me.  But I have no real good way of opting out of such sites.

So my question (yes I had one) is… is my understanding of what ASP.NET apps are doing that make this flaw so dangerous an accurate understanding?  Or have I missed something?


I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati

{ 4 comments to read ... please submit one more! }

  1. Not quite right – the attack is based on sending the site a known bad encrypted value (in a cookie, hidden field, etc) and using the type of error (via the HTTP error code) plus the time it takes for the server to generate the error give the attacked clues if they are getting “warmer” or “colder” to the private key on the server. About 60,000 tries later you should know the private key.

    The part about what’s inside the cookie is still correct, but there are parts of the ASP.NET framework that can be used with this attack that do not rely on anything the app developer did.

    In theory this attack can work on any system that doesn’t randomize the delay in responding to a failed decryption attempt. I wonder if we’ll see more frameworks and platforms targeted in the near future.

  2. thanks. i’m a little surprised that this wasn’t picked up and protected by MS earlier – the reports are that this was demonstrated against JSF several months ago. The technique isn’t that new, and certainly the ‘people only pick on MS cause they’re big’ thing doesn’t quite fly. Who the hell uses JSF? ;) But it was demonstrated there first.

    So… OK – the part about other aspects of ASP.NET being vulnerable outside of the app developer is certainly problematic – I was thinking this was solely an issue with app developers relying on auto-cookie encryption.

    Thanks!

  3. It’s a timing attack. And no, they are not being picked up earlier because nobody until very recently took the possibility of measuring the necessary timing information leaks over something like the internet seriously (even over a LAN was laughable). Last talk on the topic was at Blackhat USA in August I think, where the authors targeted OpenID and OAuth implementations (ALL languages – it’s an implementation issue, not a language issue) which leaked timing information when checking if their message signatures matched. ASP.NET is just one particularly high profile example of a dormant (unknown to most as being a problem) security issue on the horizon reported by the security community.

    The lesson is that the disclosure of timing differences between positive and negative results which has been negligible in the past as a security risk, is gaining steam as statistical measurement techniques over a network improve to eradicate the interference from the old defence (i.e. network jitter in response times).

    Also, yeah ;) . Storing stuff of a sensitive nature in a cookie is plain stupid. You might as well hang out a sign saying “Hack Me!”.

  4. It’s NOT a Timing attack. It’s caused by the missing of a MAC at the end of the encrypted data.

    Best resource on the argument:
    http://www.owasp.org/index.php/ASP.NET_POET_Vulnerability

{ 0 Pingbacks/Trackbacks }

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">



0.20065903663635