UPDATED: Security Hack Exposes Forms Authentication in ASP.NET

Two security researchers, Thai Duong and Juliano Rizzo, have discovered a bug in the default encryption mechanism used to protect the cookies normally used to implement Forms Authentication in ASP.NET. Using their tool (the Padding Oracle Exploit Tool or POET), they can repeatedly modify an ASP.NET Forms Authentication cookie (normally encrypted using AES) and, by examining the errors returned, determine the Machine Key used to encrypt the cookie. The process is claimed to be 100 percent reliable and takes between 30 and 50 minutes for any site.

Once the Machine Key is determined, attackers can create bogus forms authentication cookies. If site designers have chosen the option to embed role information in the security cookie, then attackers could arbitrarily assign themselves to administrator roles. This exposure also affects other membership provider features, spoofing protection on the ViewState, and encrypted information that might be stored in cookies or otherwise be made available at the client. The attack will reportedly work on any block-cipher encryption mechanism (e.g. 3DES, MARS) implemented using the .NET encryption tools.

Microsoft is recommending, as a workaround, reducing information returned to the client in the event of an error to prevent intruders from gathering the information needed to determine the Machine Key. You can read more on that here. The simplest solution is, in the site's web.config file, to add or replace the customErrors tag inside the system.web element. The tag should point to an error page that provides no feedback on the error. A typical entry would look like this (where error.html is some html-only page in the same folder as the web.config file):

 <customErrors mode="On" defaultRedirect="~/error.html" />

On a Web farm, these changes will have to be made on all the servers in the farm.

A video, posted Thursday, Sept. 16 on YouTube shows Thai Duong demonstrating the attack using POET. They have said they intend to provide the slide deck for their presentation on September 17 at the ekoparty Security Conference.

About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in Web development with expertise in SOA, client-side development, and user interface design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on language and technical writing can be found at

comments powered by Disqus

Reader Comments:

Mon, Apr 4, 2011 Vincent E Silver Spring, MD

I appreciate all the insight on this flaw from the security experts. How much of the web.config is exposed if most of it is stored in "configSource" files? Still the entire consolidated text?

Tue, Oct 5, 2010

They didn't "make the flaw". They discovered it, and created a way to exploit it. This flaw is in the .NET framework and has actually been around since 2002. Read this:,289142,sid14_gci1520366,00.html

Wed, Sep 29, 2010 80;s Rocker

The one thing I hate is how these 2 guys made the security flaw. IMO it was irresponsible and shows they were thinking of only one thing, getting their time in the spotlight. 1) They made a security flaw public without working with the vendors (MS, Oracle, etc) so patches could be created. 2) They not only exposed the issue, but then at a national conference showed every would be hacker just how to use the flaw to hack sites. IMO this makes them just a liable for any sites that are broken into using the hacks they showed at the conference. 3) They obviously have it in for MS, since they made sure to show how an ASP.Net site could be hacked at the conference, but I did not see them doing the same with sites created with Jave, Ruby, etc. I know MS will get a patch released ASAP, but they were thrown under the bus by the 2 people who found the flaw.

Tue, Sep 28, 2010 M T

Go and apply the patch from MS now. The workarounds suggested from MS don't work. Please refer to another demo:

Wed, Sep 22, 2010 Mark Gould BC, Canada

Everyone is wrong so far. They are not "recovering" the machine key. They use the ciphertext from the WebResource request, and are able to bruteforce encrypt their own string "R|~/web.config", once this is encrypted it is passed to ScriptResource.axd. This will then spit out, in plain text, the web.config file, enabling them to view the machine and validation key.

Wed, Sep 22, 2010 Peter Vogel Canada

Without an explicit statement by Duong and Rizzo as to which specific ciphers their exploit work against, I'm always unwilling to put words in their mouth. However, they've indicated that they believe that their exploit works against block ciphers which encrypt data while SHA-1 is a message digest cipher designed to provide a way of checking whether a message has been tampered with. However, the exploit works by taking advantage of a bug in how the blocks are padded out--presumably that bug could exist in SHA-1. With SHA-1, it's worth noting that US Government guidelines say that "agencies should stop using soon as practical" and switch to SHA-2. That's not because of problems in the .NET implementation but because of issues with the algorithm itself. That a patch for this exploit isn't out yet indicates (to me) that fixing this isn't just a "tweak" and that Microsoft is looking for any other problems. Also, this is very high-end math: it's not obvious that any change fixes the problem WITHOUT opening a new opportunity.

Tue, Sep 21, 2010 Macs Romania

Not too much to worry if you follow these strict instructions. In most cases does work and it stops the attacker from accessing your web.config file. But in the other hand if it is already compromised i´m not sure what you can do cause it had seen your connection strings to your database and thats fatal.

Tue, Sep 21, 2010 Kevin

Sorry, <machineKey> got removed from my previous post.

Tue, Sep 21, 2010 Kevin

We run our site in a web farm and therefore have the explicitly specified in the web.config. For the 'validation' attribute of that node, we have "SHA1". Are we at risk?

Tue, Sep 21, 2010

Hard to believe that this has been out so long and a) it hasn't been wide spread b) there is only a workaround, not a patch Is this truly an exploit for only sites, or others as well?

Mon, Sep 20, 2010 Becky Nagel EDITOR

Hi Guys, We had a glitch with our comment system -- trying to get the comments for this story restored ASAP. Please stay tuned!

Sun, Sep 19, 2010 Peter Vogel Canada

Yep, we do have an update coming out based on the new information from Duong and Rizzo this week. They've now demonstrated that their exploit does also work on all block cipher encryption methods, including 3DES.

Sat, Sep 18, 2010 Christian Toivola Miami, FL

This recommendation is BS - I hope they get sued because that recommendation borders on negligence. 3DES is susceptible to padding attacks as well - along with every other block cipher in CBC mode.

Sat, Sep 18, 2010 M T

This advise is completely wrong.Switching encryption doesn't help. Please read the workaround from MS advisory on this matter:

Fri, Sep 17, 2010 Jamie Gaines

The advice given in this article is flat-out wrong. Changing to 3DES will not protect you. Watch Thai Duong and Juliano Rizzo root a 3DES encrypted DNN installation in under 5 minutes.

Fri, Sep 17, 2010

The funny part about this story is that Thai's video (of him breaking DotNetNuke) breaks a 3DES key. The great thing about CBC padding and bitflips is that it's inherent to the block cipher mode; switch to DES-EDE, MARS, Twofish, or Serpent and you still have the same vulnerability. You don't even need to know how the algorithm is implemented! The same exploit will work, regardless of the underlying exploit. You gotta love crypto.

Fri, Sep 17, 2010 MB

I checked the config file and it doesn't use machineKey tag anywhere, what does that mean?

Thu, Sep 16, 2010 Peter Vogel Canada

In IIS 6 you can't make the change through Internet Services Manager--you have to make the change directly to the config files for either the website or the server.

Thu, Sep 16, 2010 Ben Kotvis

Does this fix also apply to IIS6. I see the config file but the article specifically says IIS7.

Wed, Sep 15, 2010 Peter Vogel Canada

Missed one: While SHA1 is used for some purposes in ASP.NET, AES is used to encrypt the cookie carrying forms authentication information.

Wed, Sep 15, 2010 Peter Vogel Canada

Some feedback: This affects all versions of ASP.NET from 2.0 on The problem also exists in Java, in a different format Only AES appears to be affected IIS 7 provides a way to make this change from Internet Services Management; for previous versions of IIS you'll have to update the config file using a text editor The MachineKey element is a child of the system.web element

Wed, Sep 15, 2010

Where in the web.config should the information go? System.web? System.webserver? Configuration? I am wondering why this isn't mentioned at all....

Wed, Sep 15, 2010 Al

Before worrying too much, go to and read the original paper from Rizzo and Duong (May 25th, 2010). The "padded oracle attack" relies on a chaining block cypher (common) but also requires the "oracle". As some have correctly pointed out above, we need to have ASP.NET (or Java since this is not unique to .NET) return the padding error exception. Without that information, the exploit doesn't work. By default, this exception information is not reported by ASP.NET and this is configurable behavior for Java. If you go to the aforementioned link, I think you'll find more interesting reading related to cracking CAPTCHA using this exploit. However, that too requires cooperation from the web site. It's great learning about exploits and even a little fun but the media sure scares a lot of people (and scares up a lot of clicks) by providing this hyperbole. One guy above said he was happy he used Java. Read the PDF above and you will find Rizzo and Duong found the problem with Java (JSF but also Ruby on Rails) and then turned to see if the same exploit would work with ASP.NET. Technically, it is an exploit but if it doesn't happen with properly configured servers (or the default ASP.NET configuration), it's much ado about nothing.

Wed, Sep 15, 2010 JamezJ Appleton, WI

Won't changing the encryption type at the IIS effect existing encrypted roles or passwords and thus cause users not to be able to login. Assumption: role provider stores encrypted password in database like the membership/profile providers do.

Wed, Sep 15, 2010 Ben Kotvis

Does this apply to IIS 6? I see the file there on my server but the article specifically states IIS7. Will this fix work on both versions?

Wed, Sep 15, 2010 Mark Summerville, SC USA

Are you storing sensitive data in cookies? You need to worry if not read the comments from Wed, Sep 15, 2010 Ian Lord Quebec, Canada. As far as "Glad I am using Java?" LOL they find new wholes in that once a month. If you have done your homework and built a good site then you can be proactive by learning more. All others will continue to be reactive

Wed, Sep 15, 2010 Eric

I like how they decided to let everyone wait several days for the details. Meanwhile, everyone's wondering how compromised they are. After all, getting the conference spotlight is always more important the getting the information out in a timely manner.

Wed, Sep 15, 2010

If Fips Algorithm is set in the registry for Lsa, the machinekey set to AES will not allow the site to run due to AES is not an approved Fips 140 Algorithm. So at that point 3DES would be the next choice.

Wed, Sep 15, 2010 Parrotlover77

I wonder if using custom error pages completely breaks this exploit? If you are relying on parsing the ASP.Net error messages to gain access, you will never gain access in the real world since "RemoteOnly" is the default setting. Now I'm thinking we just need more details before over-reacting and jumping to 3DES or something.

Wed, Sep 15, 2010 Parrotlover77

Colin - Based on this article, it doesn't sound like it. On the 17th, they are going to explain more detail? Great! Thanks ass-hats for making life difficult for those of us managing these sites. 3DES is not a very good workaround either as it's a fairly weak cipher. What is needed is a patch from MS to change the error messages and break the exploit.

Wed, Sep 15, 2010 SF Massachusetts, USA

Microsoft should release a patch for .NET implementation of AES. So we don't have to switch to 3DES which is a much weaker encryption.

Wed, Sep 15, 2010 John Smith Scotland

I'm using the class RijndaelManaged from the System.Security.Cryptography namespace in .NET. As Rijndael were the basis of the AES standard, is anything encrypted with this class suspect? We do use a key and an initialisation vector.

Wed, Sep 15, 2010 Corey

Wouldn't custom errors have to be off and debug turned on in order for the hacker to interpret the returned error messages?

Wed, Sep 15, 2010 Joel UK

If I have validation set to SHA1 and decryption set to AES, is my site still vulnerable to this exploit?

Wed, Sep 15, 2010 KK

we need more information since you can use different size machine keys with AES, i´m using 256 bit, 3DES default is 56 bits which sounds very small.

Wed, Sep 15, 2010 Otto G

It seems that in the default configuration (of IIS 6 and 7, at least), this would only be useful for finding out what the application chooses to store in its authentication cookies, because without knowledge of the validation key (SHA1-hashed by default), how could one create a modified cookie that would be accepted by the server as valid? See for info on the forms authentication cookie.

Wed, Sep 15, 2010 Recovering MS User, Just Linux Now

I'm pretty sure it defaults to SHA1 + AES. S/B easy fix, its in the config file.

Wed, Sep 15, 2010

Is SHA1 not the default in IIS7? So the default install should be ok? 3DES will use more resources?

Wed, Sep 15, 2010 Ian Lord Quebec, Canada

1- I find it so lame people saying thing like "Thank goodness I'm using Java!" I'm not using neither, but every piece of software is always subjet to security problem, and yes, your code also ! 2- An application relying on encryption to store sensitive content in a cookie is weak at the start. Store settings in a session var on the server and set the session ID in the cookie if you want. The worst thing that will happen is session impersonization, you won't get superadmin right and shell access to an application !. It's really easy to protect from session impersonalization. Validate ip, Agent, referer, etc.It will make it very hard for someone to hijack a session... This bug in aes encryption only affect poorly built application IMO

Tue, Sep 14, 2010

2 CORINTHIANS 6:18 NKJ 18 "I will be a Father to you, And you shall be My sons and daughters, Says the Lord Almighty."

Tue, Sep 14, 2010 Johan Johannesburg

Oh thank goodness I'm using Java!

Tue, Sep 14, 2010

Which versions of ASP.Net are affected?

Tue, Sep 14, 2010 Jaime Bula

Man! After so many years!!

Tue, Sep 14, 2010

Is AES the only encryption effected by this?

Tue, Sep 14, 2010 Colin Bowern Toronto, Canada

I hope they did the responsible thing and disclose to the vendor first to allow for an appropriate response.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.