ASP.NET and the Padding Oracle Attack: Wrap-up

11:51 AM j. montgomery 5 Comments

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


  1. One small change, in most cases (all asymmetric .NET algos) you can only decrypt with the private key (and encrypt with both the public and private key), and you can use the private key to sign data that can be verified with the public key (and private key).

  2. Thanks for taking the timne to blog about this. I have been watching developments on this front, I have worked on a number of projects which used Forms Authentication on the internet. I always suspected that there may be a vulnerability but swallowed the MIcrosoft Kool Aid anyway. I like your idea about the HTTPmodule and digital certificates I will be researching this further.

  3. I like your idea about the Digital Signatures and HTTpmodules. I will be investigating this further.

    I had always suspected there was an issues with FA but swallowed the Microsoft Kool Aid none the less. I have worked on a number of projects over the years that have used FA, so have been watching developments on this front with particular interest.

  4. I wrote an HttpModule-based solution to the padding oracle exploit. It incorporates the digital signature idea mentioned above.

    The project is up at and licensed under Apache 2. Right now, it's got 2 main features relating to the padding oracle expoit:

    1) It stores FormsAuthenticationCookie and FormsAuthenticationTicket information on the server at the time the ticket is issued. It uses this information to strengthen ticket validation... a LOT. Even if your machine keys are compromised, nobody can create a FormsAuthenticationCookie that will pass validation.

    2) It detects & prevents certain known padding oracle attack vectors (CryptographicException's on .axd requests) -- returns 200 codes where 404's or 500's are expected & introduces delays to the response. / for more info


  5. Excellent. I look foward to checking it out when I get a chance.