ASP.NET and the Padding Oracle Attack: Wrap-up
I'm no crypto expert (I do know the basics) and it's been a challenge to wrap my head around the nuances of this Padding Oracle vulnerability in ASP.NET.Initially, based on the news that was released it sounded like an issue with AES since they never mentioned 3DES. It turns out that this was false and that this attack works against ANY BLOCK CIPHER meaning 3DES was also vulnerable. I suspected it was premature to suggest this as a valid mitigation technique at the time and said so, and it turns out I was correct at least about that part.
Microsoft posted that the work-around was to turn custom errors On because the attack needs to know "which error code was returned by the server" - from all of my discussions, research, and reading on this attack, it's clear to me that this is not going to completely solve the issue. All an attacker needs to do is INFER if encryption was successful or unsuccessful.
Now on Scott Guthrie's blog a series of 'mitigation' techniques have been released that will help, but still none of the actually get to the heart of properly solving the issue - which is fine since Microsoft should move to fix this in the Framework. The combination of techniques recommended will do a good job both slowing attackers down and not providing good information about successful/unsuccessful decryption - slowing down or stopping the oracle. So definitely take steps in this direction.
One thing we always stress in Software Security is Input Validation - systems need to be programmed to securely handle untrusted input that come from clients. The Forms Authentication Ticket is pushed down to the client and then get's submitted back to ASP.NET without checking to see if it's been modified or if it can be considered trusted. The problem with symmetric encryption, which is used to encrypt the Forms Auth Ticket, is that there's no way to know if the cipher-text can be trusted since it's just data blob - so ASP.NET happily accepts any data and starts crunching on that data before verifying that it can actually trust the data.
This is what a Digital Signature can be used for. Digital Signatures are based on both Asymmetric encryption (or Public Key Cryptography) and Hashes. Asymmetric encryption allows one party to encrypt data with their private key, a key no one else should know. Then anyone with their public key (a key that's safe to make publicly known) can validate the person in possession of the private key sent the message. This is done by decrypting the message with the public key.
A Digital Signature then is when a hash of the message to be signed is generated and then encrypted using the private key. This signature can then be included and used to check to see if the message was changed (HASH) and if it was signed (hash encrypted with private key) by the person who was in possession of this private key...
A good way to protect against the Padding Oracle attack against ASP.NET is to us a Digital Signature to sign the Forms Auth Ticket. Signing the Forms Auth Ticket with a digital signature would provide the following protections:
1. Detect if the Forms Auth Ticket was modified
2. Detect if the Forms Auth Ticket modification was unauthorized
If the Signature is invalid - throw it out -it's untrusted. This type of Input Validation could be applied to the Forms Auth Ticket as well as any other data encrypted and sent down to the clients. ASP.NET would not have to bother trying to decrypt the messages protected by the Symmetric key unless the signature could be validated, thus eliminating the oracle. This prevents anyone else from generating or attempting to generate Forms Auth Tickets except the ASP.NET web server server - so EVEN IF THE ATTACKER WAS IN POSSESSION OF THE MACHINE KEY, they still wouldn't be able to create a trusted Forms Auth Ticket without the asymmetric private Key used to encrypt the hash.
I suspect a HttpModule could be written to add signature data for Forms Auth Ticket Cookie, Role Cookies, etc. in ASP.NET and then validate them when they are submitted back to the client...
5 comments: