How serious is this new ASP.NET security vulnerabi

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.

Answer 1

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.

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.

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.

Answer 4

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