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

ASP.NET and the Padding Oracle Attack

12:14 AM j. montgomery 3 Comments

UPDATE: Read my final analysis and wrap-up here: http://securitythroughabsurdity.com/2010/09/aspnet-and-padding-oracle-attack-wrap.html

The Padding Oracle attack affects all block ciphers that are configured to use CBC + PKCS7...and it's been demonstrated that both AES and 3DES are both vulnerable to this attack in ASP.NET. Once the machine key is recovered it appears that the Forms Auth Tickets (and any other encrypted element) can be decrypted and re-encrypted allowing a full compromise of any ASP.NET Web Site that relies on Forms Authentication. Additionally MS revealed that on Framework 3.5+, even arbitrary files could be retrieved from the web server due to this vulnerability, though I'm not clear as to why this would be possible:

"If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file which the worker process has access to will be returned to the attacker."

Watch this video on youtube POET vs ASP.NET: DotNetNuke to see Dot Net Nuke using 3DES getting Pwnt using 3DES with Custom Errors OFF.

It appears from the video that if Custom Errors are ON, then the Oracle isn't present and the attack may not succeed.

This is a serious vulnerability for ASP.NET web sites that have CustomErrors set to 'Off' - out of the box ASP.NET is secure, as it's default setting is 'RemoteOnly'.

More information as well as a script to detect web sites with CustomerErrors set to 'Off' here: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

Vulnerability In .NET Crypto Puts ASP.NET Web Sites at Risk

4:42 PM j. montgomery 2 Comments

UPDATE: Read my final analysis and wrap-up here: http://securitythroughabsurdity.com/2010/09/aspnet-and-padding-oracle-attack-wrap.html

ASP.NET web applications that leverage Forms Authentication, ASP.NET Membership Providers, ASP.NET Role Providers, and/or ViewState encryption are vulnerable to data exposure and potentially tampering. Details to be given this Friday, Sept. 17th at the ‘ekoparty Security Conference’ in Buenos Aires.

'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Applications
"It's worth noting that the attack is 100% reliable, i.e. one can be sure that once they run the attack, they can exploit the target. It's just a matter of time. If the attacker is lucky, then he can own any ASP.NET website in seconds. The average time for the attack to complete is 30 minutes. The longest time it ever takes is less than 50 minutes," Duong said.”

Padding oracles everywhere
“The second part presents a previously unknown advanced attack. The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!”
Presented by Rizzo and Duong

This technique allows the attacker to discover the AES Machine Key used by various ASP.NET features to encrypt and decrypt data stored on the web client.


There is a vulnerability in the AES algorithm implementation in .NET. This might be a bit premature, since the presentation details haven’t been given but a quick mitigation should be to switch over to 3DES instead of AES to protect your web sites. Hopefully a patch from Microsoft will be released that will solve this issue.

By default ASP.NET 2.0+ uses AES to protect ViewState, Forms Authentication, Roles, Membership, etc. and is vulnerable to attack. Depending on how an ASP.NET applications is architected/configured will determine if you are vulnerable.

For IIS 7 (Windows Server 2008, Win7, Vista) – the encryption settings (system wide, or application specific) can be configured directly in the IIS Manager. Under ASP.NET settings, choose “Machine Key” and make the changes through the GUI. You can do it Server Wide, or for each application.


If on an older version of IIS, you can make the changes to the .NET config files directly. Configuration Files are located in many folders depending on the versions of the .NET Framework that are installed. On a 64-bit machine, there is a separate configuration file for 64-bit.

• %SYSTEMROOT%\Microsoft.NET\Framework\[version number]\CONFIG\
• %SYSTEMROOT%\Microsoft.NET\Framework64\[version number]\CONFIG\
• The web.config in your web application folder

Ref: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx (.NET 4.0 docs):

• validation attribute specifies how to handle ASP.NET ViewState – when it’s been configured to encrypt…you may want to leave this to SHA1 and then change it in the local web.config instead.
  
• decryption attribute handles which algo is used to encrypt/decrypt Forms Authentication Data (Forms Auth Ticket/Cookie), Membership Data (including Anonymous Identification), Role Cookies, – If it’s set to auto, that means you are using AES in .NET 2.0+ and you will be vulnerable.

Be careful, machinekey settings much match across all servers in a web farm. If a decryption key was specified (typically a web farm) then you’ll need to generate a new 3DES key and duplicate it across all servers in the web farm.

For more information on configuring Machine Keys in .NET 2.0:
http://msdn.microsoft.com/en-us/library/ms998288.aspx (depreciated, but still useful)

As always, determine if you actually have a vulnerability first, and THEN TEST ALL SETTINGS before modifying your production environment.