PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

asp.net oracle padding flaw - question?

Note: This article was originally published at Planet PHP on 30 September 2010.
Planet PHP

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. AThis really does seem to be the case though. AWatching the DNN exploit, it looks like the fact that someone is a superuser is encoded in the cookie value itself. AThis 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. AThis 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. AThis was thought of as asecure' because encryption was being used. AI tried to argue for random values as the cookie token, but was told that arandom isn't really random'. AI 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. AMy concerns were dismissed because I wasn't a asenior' engineer, apparently I didn't understand Java or cryptography enough to understand their level of sophistication. AAfter all, arandom 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. ABut I have no real good way of opting out of such sites.

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