How serious is this new ASP.NET security vulnerability and how can I workaround it?

Question

I've just read on the net about a newly discovered security vulnerability in ASP.NET. You can read the details here.

The problem lies in the way that ASP.NET implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions.

This is a bit vague, but here is a more frightening part:

The first stage of the attack takes a few thousand requests, but once it succeeds and the attacker gets the secret keys, it's totally stealthy.The cryptographic knowledge required is very basic.

All in all, I'm not familiar enough with the security/cryptograpy subject to know if this is really that serious.

So, should all ASP.NET developers fear this technique that can own any ASP.NET website in seconds or what?

How does this issue affect the average ASP.NET developer? Does it affect us at all? In real life, what are the consequences of this vulnerability? And, finally: is there some workaround that prevents this vulnerability?

Thanks for your answers!

---

EDIT: Let me summarize the responses I got

So, this is basically a "padding oracle" type of attack. @Sri provided a great explanation about what does this type of attack mean. Here is a shocking video about the issue!

About the seriousness of this vulnerability: Yes, it is indeed serious. It lets the attacker to get to know the machine key of an application. Thus, he can do some very unwanted things.

• In posession of the app's machine key, the attacker can decrypt authentication cookies.
• Even worse than that, he can generate authentication cookies with the name of any user. Thus, he can appear as anyone on the site. The application is unable to differentiate between you or the hacker who generated an authentication cookie with your name for himself.
• It also lets him to decrypt (and also generate) session cookies, although this is not as dangerous as the previous one.
• Not so serious: He can decrypt the encrypted ViewState of pages. (If you use ViewState to store confidental data, you shouldn't do this anyways!)
• Quite unexpected: With the knowledge of the machine key, the attacker can download any arbitrary file from your web application, even those that normally can't be downloaded! (Including Web.Config, etc.)

Here is a bunch of good practices I got that don't solve the issue but help improve the general security of a web application.

• You can encrypt sensitive data with Protected Configuration
• Use HTTP Only cookies
• Prevent DoS attacks

Now, let's focus on this issue.

• Scott Guthrie published an entry about it on his blog
• ScottGu's FAQ blog post about the vulnerability
• ScottGu's update on the vulnerability
• Microsoft has a security advisory about it
• Understanding the vulnerability
• Additional information about the vulnerability

The solution

• Enable customErrors and make a single error page to which all errors are redirected. Yes, even 404s. (ScottGu said that differentiating between 404s and 500s are essential for this attack.) Also, into your Application_Error or Error.aspx put some code that makes a random delay. (Generate a random number, and use Thread.Sleep to sleep for that long.) This will make it impossible for the attacker to decide what exactly happened on your server.
• Some people recommended switching back to 3DES. In theory, if you don't use AES, you don't encounter the security weakness in the AES implementation. As it turns out, this is not recommended at all.

Some other thoughts

• Seems that not everyone thinks the workaround is good enough.

Thanks to everyone who answered my question. I learned a lot about not only this issue, but web security in general. I marked @Mikael's answer as accepted, but the other answers are also very useful.

Wring

@TimS - Thanks. :) To be honest, I'm really worried about this issue, thus the question. – Wring

Venemo, can I just say that I do not think this is a good place for this request (judging by the answers). Voting is not a good way to resolve this question, it needs to be answered by an expert (and you don't need to be an expert to vote). I recommend: mail-archive.com/[email protected]/maillist.html or, as someone below mentioned, the official comment from Microsoft, which is to not send any error messages to the client. This is the correct approach. Do not downgrade to 3DES. It is shocking advice. – Rollicking

More from MS: blogs.technet.com/b/srd/archive/2010/09/17/… – Barbiturate

What nobody seems to have explained so far is whether implementing Application_Error in global.asax is just as good as the proposed customErrors workaround for this issue. – Nyssa

@Noon - Good point. But I won't choose the answer according to votes. :) Rather by the reasoning in them. I'm also curious about the answers of anyone, and (as you can see) real experts arrived eventually. – Wring

@Hightechrider Yes, I would also like to know the answer to this - I have some apps which count on this instead of a redirect specified in web.config. Anyone know if they have the same effect? – Ophidian

@Andy, read ScottGu's blog post about the issue, that explains many things. :) – Wring

Wow, 300+ rep points for posting a question to which no-one here can really have the "correct answer". Not a bad days rep-whoring. =) – Dardani

@Dardani - I do not agree. There are lots of usable responses here. @Dan, why? – Wring

Okay, we have different interpretations of a question on SO. To me, if it can be correctly answered, then fine. The answers are interesting/helpful, dont get me wrong, but this to me is an issue where the only "answer" is a workaround - until MS release a fix. To me, this should be a wiki. – Dardani

@Dardani - Since the question itself asks for a workaround, I don't think it is a problem that the answer is a workaround. :) – Wring

Can you also block this by throttling your site so it restricts aspx requests to 1 per 10 seconds? Over 8 hours of brute forcing – Babbette

@Venemo, you're missing the point. It's valid we should discuss this issue, but it should be a community wiki, so people can share their thoughts/workarounds, without "reputation" being the driver for the contribution. Anyway, rant over. =) – Dardani

@Chris - I don't think that would be applicable to any real world application... And if the data on your site is worth 8 hours of bruteforcing, someone will do 8 hours of brute forcing against it. – Wring

I wasn't thinking dell.com would use that technique, but for the lonely blog site with 100 visits per day, it would be a good deterent along with the web.config change – Babbette

As I understand it, this workaround requires that you send the same HTTP response code (likely 200) to the client as well as send the client to the same page for all errors. Is this true? Will the attack still be viable if your server returns several different error codes (302, 403, 404, 200, etc.) for various errors? – Dusty

In case anyone came back to this thread looking for the security fix, they're located at microsoft.com/technet/security/bulletin/MS10-070.mspx (choose your OS and .NET version). – Ophidian

Answer 1

What should I do to protect myself?

[Update 2010-09-29]

Microsoft security bulletin

KB Article with reference to the fix

ScottGu has links for the downloads

[Update 2010-09-25]

While we are waiting for the fix, yesterday ScottGu postet an update on how to add an extra step to protect your sites with a custom URLScan rule.

---

Basically make sure you provide a custom error page so that an attacker is not exposed to internal .Net errors, which you always should anyways in release/production mode.

Additionally add a random time sleep in the error page to prevent the attacker from timing the responses for added attack information.

In web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

This will redirect any error to a custom page returned with a 200 status code. This way an attacker cannot look at the error code or error information for information needed for further attacks.

It is also safe to set customErrors mode="RemoteOnly", as this will redirect "real" clients. Only browsing from localhost will show internal .Net errors.

The important part is to make sure that all errors are configured to return the same error page. This requires you to explicitly set the defaultRedirect attribute on the <customErrors> section and ensure that no per-status codes are set.

What's at stake?

If an attacker manage to use the mentioned exploit, he/she can download internal files from within your web application. Typically web.config is a target and may contain sensitive information like login information in a database connection string, or even link to an automouted sql-express database which you don't want someone to get hold of. But if you are following best practice you use Protected Configuration to encrypt all sensitive data in your web.config.

Links to references

Read Microsoft's official comment about the vulnerability at http://www.microsoft.com/technet/security/advisory/2416728.mspx. Specifically the "Workaround" part for implementation details on this issue.

Also some information on ScottGu's blog, including a script to find vulnerable ASP.Net apps on your web server.

For an explanation on "Understanding Padding Oracle Attacks", read @sri's answer.

---

Comments to the article:

The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.

If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.

In order for the attack to work the following must be true:

• Your application must give an error message about the padding being invalid.
• Someone must tamper with your encrypted cookies or viewstate

So, if you return human readable error messages in your app like "Something went wrong, please try again" then you should be pretty safe. Reading a bit on the comments on the article also gives valuable information.

• Store a session id in the crypted cookie
• Store the real data in session state (persisted in a db)
• Add a random wait when user information is wrong before returning the error, so you can't time it

That way a hijacked cookie can only be used to retrieve a session which most likely is no longer present or invalidated.

It will be interesting to see what is actually presented at the Ekoparty conference, but right now I'm not too worried about this vulnerability.

Nomenclature

@Mikael, great answer, but could you please post actual examples of the solutions you recommend? Eg. "Store a session id in the crypted cookie" how do I do that? AFAIK session state management and the authentication cookie are two distinct things in ASP.NET. The "Store the real data in session state" part is okay. But... "Add a random wait when user information is wrong before returning the error"... basically my question is, what error? Will this stuff throw an exception that I can catch somewhere? Is it covered by Custom Error Messages or Application_Error? – Wring

@Venemo. Istead of Response.Cookies.Add( new HttpCookie("role", "admin")); you would do: string sessionId = Guid.NewGuid().ToString(); Session[sessionId] = "role=admin"; Response.Cookies.Add( new HttpCookie("s", sessionId)); and the attack is susceptible to measure the timing of responses to figure out the crypto. So add a Thread.Sleep(...) at the end of a response would prevent such timings. As for the error I assume (and is almost certaint) it's an app error, but need to test this some myself. So having custom error pages would not show the padding error. – Nomenclature

@Mikael, thank you! Anyways, what sense would it make to store roles in a cookie? Am I secure if I use Roles.AddUserToRole("Joe", "Admin") but I never actually store that in a cookie? – Wring

@Venemo: Read my edit and the link to the blog post. Typically Form login sites store the role in a cookie, but as @Aristos mention in his response, this can be turned off, and should be turned off. – Nomenclature

@Mikael, I've read it. I also put this element into my Web.config. Thanks! My worries have lessened now. :) – Wring

What on earth ...; do NOT downgrade to 3DES, this won't help at all, and is really bad advice. – Rollicking

@Mikael: Please, for the benefit of applications everywhere, delete that component of your answer, and link to Microsofts specific advice (I don't want to edit your answer and speak for you, but I believe it is only responsible that your advice be removed). – Rollicking

@Noon. Edited my answer and linked in the official response. – Nomenclature

@Mikael you can also add a link to ScottGu's blog, which has some additional info: weblogs.asp.net/scottgu/archive/2010/09/18/… – Maurer

@Eilon: Thanks. Also linked in the script which you can use to check if you haven't turned on custom errors on your apps. – Nomenclature

@Mikael Can you explain (using small words :) ) what difference the timing part makes? – Deeplaid

By timing the error response you gain more information about which underlying system was used. By adding a random sleep, and packing 404 and 500 errors in a custom page which is returned with a 200 status code, you hide this. en.wikipedia.org/wiki/Timing_attack – Nomenclature

@Deeplaid - First, read my answer for context. The attacker needs to figure out between outcome 2 and 3. To figure out if its a valid account number, your code may take 1 second, whereas to flag a cryptographic error, it probably just takes 10 ms. So, an attacker with a stop-watch can easily figure out between the two outcomes even if they both show the exact same error page. Adding a random delay makes the stop-watch idea infeasible. – Gangboard

I have some apps that have custom errors mode "RemoteOnly". Do you all think it's necessary to go through and change them all to "On"? – Ophidian

@Andy: Good comment. You can safely keep it at RemoteOnly. The important part is to set defaultRedirect and have all errors go to the same page. RemoteOnly will let you get .Net errors when accessing the page from localhost, while clients coming in from the outside gets the custom error page. This allows you to debug from the local server if necessary, to see what error was generated. How important this is depends much on what other logging you have implemented. – Nomenclature

Your answer seems to imply that cookies are the primary target and that "someone must sniff data" in order to target you. This isn't true. For some applications (those using .NET 3.5 SP1 or later, I believe) might also give up the web.config (or other aribtrary files) using this attack... far more serious. – Arleenarlen

@user177367. Cookies and ViewState are the attack vectors. If you manage to use them to break the crypto, then a skilled attacker can forge a key and use a feature of ASP.Net to download your web.config. The feature is normally used for accessing css and js files. – Nomenclature

@user177367: Edited my answer to say what's at risk with the exploit, and mention that you should encrypt sensitive information in your web.config. – Nomenclature

@Mikael You say "In order for the attack to work the following must be true: Someone must sniff data [and] Your application must give an error message about the padding being invalid." From what I read, that's not true-- the attack doesn't require sniffing nor does it require specific error messages (rather it can analyze the timing of the error messages it receives, also known as side-channel information). – Arleenarlen

'@Mikael - user177367 is right. The word 'sniff' is confusing. The attacker doesn't have to listen to someone else's communication. He just needs to get any encrypted viewstate value, and that doesn't need sniffing. – Gangboard

Answer 2

Understanding Padding Oracle Attacks

Lets assume your application accepts an encrypted string as a parameter - whether the parameter is a cookie, a url parameter or something else is immaterial. When the application tries to decode it, there are 3 possible outcomes -

1. Outcome 1 : The encrypted string decrypted properly, and the application was able to make sense of it. Meaning, if the encrypted string was an 10 digit account number, after decryption the application found something like "1234567890" and not "abcd1213ef"

2. Outcome 2 : The padding was correct, but after decryption the string obtained was gibberish that the app couldn't understand. For example, the string decrypted to "abcd1213ef", but the app was expecting only numbers. Most apps will show a message like "Invalid account number".

3. Outcome 3 : The padding was incorrect, and the application threw some kind of error message. Most apps will show a generic message like "Some error occurred".

In order for a Padding Oracle attack to be successful, the attacker must be able to make several thousands of requests, and must be able to classify the response into one of the above 3 buckets without error.

If these two conditions are met, the attacker can eventually decrypt the message, and then re-encrypt it with whatever he wishes. Its just a question of time.

What can be done to prevent it?

1. Simplest thing - anything sensitive should never be sent to the client, encrypted or no encrypted. Keep it on the server.

2. Make sure that outcome 2 and outcome 3 in the above list appear exactly the same to the attacker. There should be no way to figure out one from the other. This is not all that easy, though - an attacker can discriminate using some kind of timing attack.

3. As a last line of defence, have a Web Application Firewall. The padding oracle attack needs to make several requests that look almost similar (changing one bit at a time), so it should be possible for a WAF to catch and block such requests.

P.S. A good explanation of Padding Oracle Attacks can be found in this blog post. Disclaimer: Its NOT my blog.

Gangboard

+1 Great explanation, thanks! One question: "Make sure that outcome 2 and outcome 3 in the above list appear exactly the same to the attacker." -> How can I achieve this in ASP.NET? – Wring

In order for them to appear the same, you should output the same error message for outcome 2 and 3, meaning a more generic error. That way they can't be differentiated upon. A good error could be: "An error occurred, please try again". The drawback could be that you give less informational messages to the user. – Nomenclature

So how does this let people download the web.config?? – Meras

@Lavinski - No clear information yet, but it is believed that WebResource.axd allows you to download web.config (and other resources) if you give it the right key. And to generate the key, one needs the padding oracle. – Gangboard

Answer 3

From what I read until now...

The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances

They need the encrypted cookie of a user that have been already logged in, on any account. They also need to find data in cookies - I hope that developers do not store critical data in cookies :). And there is a way that I have below to not let asp.net store data in the login cookie.

How can someone get the cookie of a user that is online if he doesn't get his hands on the browser data? Or sniff the IP packet ?

One way to prevent that is to not allow cookies to transport without ssl encryption.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Also one more measure is to prevent storing Roles in cookies.

<roleManager enabled="true" cacheRolesInCookie="false">

Now about the cookies that are not secure for the regular pages, this needs some more thinking what you left your user do and what not, how you trust him, what extra check you can do (for example if you see a change on the ip, maybe stop trust him until relogin from security page).

Reference:
Can some hacker steal the cookie from a user and login with that name on a web site?

How to check from where attacks come and not give back informations. I wrote here a simple way to prevent the padding is invalid and logging at the same time to track down attackers: CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed

The way to track the attacker is to check the padding is invalid. With a simple procedure you can track them down and block them - they need some thousands of call on your page to find the key !

Update 1.

I have download the tool that suppose that's find the KEY and decrypt the data, and as I say its trap on the above code that's check the viewstate. From my tests this tool have many more to fix, for example can not scan compressed view state as it is and its crash on my tests.

If some one try to use this tool or this method the above code can track them down and you can block them out of your page with simple code like this one "Prevent Denial Of Service (DOS)", or like this code for preventing Denial of service.

Update 2

Its seems from what I read until now that the only think that is really need it to not give information back about the error, and just place a custom error page and if you like you can just create and a random delay to this page.

a very interesting video on this issue.

So all the above its more measure for more protections but not 100% necessaries for this particular issue. For example to use ssl cookie is solve the snif issue, the not cache the Roles in cookies it good to not send and get back big cookies, and to avoid some one that have all ready crack the code, to just place the admin role on the cookie of him.

The viewstate track its just one more measure to find attack.

Obe

Aristos, so, after all, this pretty much looks like any other generic cookie-stealing-based method, right? So why do they say that it is sooo serious? – Wring

@Wring because if they really can get that key maybe can make some more damage on the post on the data on any page because they break that security... it is serious but its also hard to impossible to move to the next step and real break on the system. For example this site mypetfriend.gr allow sql injection. But can you break it ? even if the security is so low ? – Obe

@Wring I think the final wraparound that you ask especial on this attack is to track down and lock the Ips that product invalid padding more than the normal ! (and this is what I am going to fix in the next days) :) – Obe

@Obe - I read your answer to the other question you linked. It deals with Viewstate though. Since I use ASP.NET MVC, I don't use ViewState. And I couldn't figure it out, how does that description translate to this security issue? – Wring

@Wring for MVC I can not say because I do not know. The ViewState is the part that attacks to find the key. How MVC track the integrity of the page I do not know. – Obe

@Obe - It doesn't do anything like ViewState by default. (One needs to explicitly take care of it.) See my answer here about it: #2798868 – Wring

@Obe I think the seriousness here is that it allows the attacker to get to the key used for session cookies and view state. By default this is created anew each time the app is started. But if you want to have sessions that out-live process lifetimes or a web farm set up you need to fix the key. This means the attacker will be able in inject arbitrary data values into the view state or change session until you modify the key in the configuration. – Monetary

@Monetary - So if I don't have ViewState (as I use MVC) then only my session/authentication cookies are in danger. Right? – Wring

@Venemo: And any files that are not normally served, including web.config. – Monetary

@Obe do you know if Session & Auth tickets suffer from exposing info on padding oracle? As @Wring said, MVC doesn't have ViewState, so the attack must be done from elsewhere (I know WebResources and ScriptResources suffer from it, but say those are disabled). – Hymnist

@Obe of course I meant the session id in the cookie and the auth ticket ;) ... see the answer I added / mentioned that in there. – Hymnist

@Hymnist sorry miss that... The session id - I do not think how can some one get it with our sniff it, and its only a random string. The auth ticket ether is a random string, ether the name of the user encoded. From the video I have see I think that is the name of the user encoded. So this is the infos on this 2. – Obe

Answer 4

Here is the MS response. It all boils down to "use a custom error page" and you won't be giving away any clues.

EDIT
Here is some more detailed info from scottgu.

Eatable

Thanks, this is what I have been asking all along. So basically a simple custom error page can save me from all the implications of this vulnerability? – Wring

@Venemo: Yes, and the people recommending 3DES really should be silenced; it's unbelievably irresponsible and doesn't even address the main issue! It's quite shocking. Please, I hope no-one follows their advice and does what Microsoft official advises. – Rollicking

@Noon - Well, this sort of custom error page is a must have for any production site, so as it turns out, this issuse is not so serious after all. :) – Wring

Answer 5

Adding ScottGu's responses taken from discussion at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Is custom IHttpModule instead of customErrors affected?

Q: I don't have a element declared in my web.config, I have instead an IHttpModule inside the section. This module logs the error and redirects to either a search page (for 404's) or to an error page (for 500's). Am I vulnerable?

A: I would recommend temporarily updating the module to always redirect to the search page. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now I'd recommend not differentiating between 404s and 500s to clients.

Can I continue using different errors for 404 and 500 errors?

Q: I take it we can still have a custom 404 page defined in addition to the default redirect on error, without violating the principles described above?

A: No - until we release a patch for the real fix, we recommend the above workaround which homogenizes all errors. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now you should not differentiate between 404s and 500s to clients.

How does this allow exposure of web.config?

Q: How does this allow exposure of web.config? This seems to enable decrypting of ViewState only, is there another related vulnerability that also allows the information disclosure? Is there a whitepaper that details the attack for a better explanation of what's going on?

A: The attack that was shown in the public relies on a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application). We will obviously release a patch for this - until then the above workaround closes the attack vector.

EDIT: additional FAQ available in the second blogpost at http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Cockeyed

The Answer to the second question ends with two asterisks. Is there suppose to be some footnote or qualifier text added somewhere? – Sawbuck

@Scott Mitchell: No, it's only my typo. (the part of text was bold in the first version of the post and I've forgot to remove all the formatting code when the text was edited). Fixed. Sorry for misguiding you. – Cockeyed

Answer 6

IMO, there is no across-the-board prevention for this, it needs to be handled on a case-by-case basis:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Aflame

Answer 7

A few significant links:

• MS' Security Advisory 2416728 (this is the official information)
• Additional information from MS' Security Research & Defence team
  • "Understanding the ASP.NET Vulnerability" (2010-09-17)
  • "Additional Information about the ASP.NET Vulnerability" (2010-09-20)
• Scott Gu: "Important: ASP.NET Security Vulnerability" (2010-09-18)

[To answer the seriousness aspect of this (what has been published and workarounds are covered by other answers).]

The key being attacked is used to protect both view state and session cookies. Normally this key is generated internally by ASP.NET with each new instance of the web app. This will limit the scope of damage to the lifetime of the worker process, of course for a busy application this could be days (i.e. not much of a limit). During this time the attacker can change (or inject) values into the ViewState and change their session.

Even more seriously if you want sessions to be able to span worker process lifetimes, or allow web farms (i.e. all instances in the farm can handle any user session) the key needs to be hard coded, this is done in web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Those are, of course, newly created keys, I use the following PowerShell to access Windows cryptographic random number generator:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Using an array length of 20 for the validation and 16 for the decryption keys.)

As well as modifying the public error pages to not leak the specific error, it would seem a good time to change the above keys (or cycle worker processes if they have been running for a while).

[Edit 2010-09-21: Added links to top]

Monetary

By default worker processes are recycled after 27-29 hours (depending on your IIS version) if they last that long, so you shouldn't have one around for days, even on a heavily trafficked site. – Visceral

Answer 8

I just posted my full take on this in my blog, after extra research on the issue. I think its important clearing out why they are getting as far as forging an auth cookie.

---

Just want to get some facts straight:

1. attack doesn't let you get the machine key directly. That said, its pretty much like it had, as it allows to decrypt the messages, and modify re/encrypt new ones.
2. the way the get the actual keys is by using their ability to modify re/encrypt as in 1 and get the web.config. Unfortunately there are reasons why some put these keys in the web.config at the site level (different discussion), and in the sample video they benefit from that being the default of DotnetNuke.
3. to get the web.config all out there points to that they are using webresources.axd and/or scriptresources.axd. I thought these worked only with embedded resources, but it seems that's just not the case.
4. if the app is asp.net MVC we don't really need webresources.axd and/or scriptresources.axd, so those can be turned off. We also don't use viewstate. That said, its unclear to me if any of the other asp.net features gives different info with the workaround in place i.e. I don't know if padding gives invalid results in error while padding valid results in ignored authentication ticket (don't know if its or not the case) ... the same analysis should apply to the session cookie.
5. asp.net membership provider 'caches' roles in cookies, turn that off.

About 1, afaik the encrypted messages can't be 100% arbitrary need to tolerate a tiny piece of garbage somewhere in the message, as there is 1 block in the message which decrypt value that can't be controlled.

Finally I would like to say that this issue is the result of ms not following its own guidance in this case: a feature relies on something sent to the client being tamper proof.

---

More on:

I don't know if padding gives invalid results in error while padding valid results in ignored authentication ticket (don't know if its or not the case) ... the same analysis should apply to the session cookie.

The auth cookie is signed, and from the info in the paper they shouldn't be able to generate a signed cookie if they don't get to the actual keys (as they did in the video before forging the auth cookie).

As Aristos mentioned, for the session id in the cookie, that's random for the user session, so it'd have to be sniffed from an user with the target security level and cracked while that session is active. Even then if you are relying in authentication to assign/authorize the user operations, then the impact would be minimal / it'd depends a lot in what Session is used for in that app.

Hymnist

Answer 9

A patch for this bug has been released on Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Googol

Answer 10

Asp.Net MVC is also affected by this problem (as is Sharepoint, ...)

I've covered the fix for MVC here: Is ASP.NET MVC vulnerable to the oracle padding attack?

Anthologize