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

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

Answer 2

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

Answer 3

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]

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.

Answer 5

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?

Answer 6

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.