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.

iis MachineKey2

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):
<configuration>


  <system.web>


    <machineKey validationKey="AutoGenerate,IsolateApps" 

        decryptionKey="AutoGenerate,IsolateApps" 

        validation="3DES" decryption="3DES" />  

  • 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.
kick it on DotNetKicks.com

2 comments:

  1. Mine was already defaulted to SH1 which is much better than 3DES anyhow...

    ReplyDelete
  2. If you don't need encryption, SHA1 is certainly the way to go!

    ReplyDelete