Security Vulnerability in ASP.NET

*Puff*

Hi there.
As i understand, episerver redirects to a standard error page if a server error occurs and the user isn't authenticated. In my eyes, this eliminates the vulnerability. Am i wrong?

The key for this workaround to work as intended is to hide all information about what type of error occured, including http status code, etc.

ScottGu elaborates a bit on the proposed workaround in a blog post at: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Ok, so what you are saying is that the episerver default error page does not hide the http status codes, etc? - and therefor the vulnerability still exists?

After more reseach i've concluded that what the work around does, is it hides the differences between a 404 and a 500 error for the attacker.
The episerver error page redirect correctly gives 404 or 500 in the response header. Therefore the work-around needs to be implemented on episerver sites aswell.
in EPiserver 4, You need to:
1) implement the work around
2) disable episerver error handling by setting the appConfig key EPsErrorHandling to "Off"

We got it working on EPiServer CMS 6 with:
1) Implement fix.
2) In EPiServer.config set globalErrorHandling="Off".
3) re-save web.config or recycle app-pool (restart website)

More reading:
http://labs.episerver.com/en/Blogs/LBi/Dates/2009/9/Creating-Custom-Error-Pages-in-EPiServer-CMS-5/

read especially step 5+6

Martin, you're correct as far as I could figure from the available information. EPiServer has different status codes and error pages for different server side errors (and 404 is absolutely an error).

The proposed solution from Microsoft is to include a random sleep on the error page if you're on FW 3.5 SP1 or later, to make it harder for anyone that tries to hack your site to see patterns. An error page with a long response time could mean that the attack was successful in accessing a resource further back in the infrastructure - like the database for an example.

Important: If you have some sort of custom 404 solution you need to disable it for the time being.

Some slight clarification about what needs to be done:

You must ensure your site does not become able to answer the following question: "When sent manipulated encrypted data such as ViewState - is the padding incorrect?".

That's what it means to be a 'Padding Oracle'. As long as your site does not enable an attacker to get an answer to that single question, the attack does not apply. You do not want your site to be Padding Oracle, but that's also all.

Therefore, it's generally not necessary to disable custom 404 solutions etc. It's perfectly fine to respond differently to different error situations - as long as an attacker cannot determine yes/no to whether it's specfically an issue with padding being correct or not. Your site must not directly or indirectly (via timing for example) let an attacker know that the problem is "CryptographicException: Padding is invalid and cannot be removed".

For some further background and explanation, as well as reference to the original papers describing both the theory and the practical application of the vulnerability, please see my (non-EPiServer related) blog at http://www.axantum.com/Blog/post/About-the-ASPNET-Padding-Oracle-Attack.aspx .

While the issue is very serious, react properly and correctly - and do remember that this has been published and known for 8 years... Let's just hope the black hats are as inattentive as the major software vendors are! Or rather, don't. Assume they are not! If you have real reason to worry, start going through your old logs for lots of cryptographic exceptions...

That is an excellent blog post Svante. Thanks.

About the custom 404 pages, Scott Guthrie has a note about it on the blog post referred above: "One of the ways this attack works is that looks for differentiation between 404s and 500 errors."

I guess Microsoft reasons that there are just to many vulnerable sites out there, and is better safe than sorry, so anything goes. I'm inclined to follow the same logic in this case (lots of different EPiServer and 404 solutions out there). But, people need to think for themselves. Generally, if you're not sure, do as much as you can (following Microsoft's advise which should also render your custom 404 solution useless.)

Yes, Steve - you're right. Better safe than sorry.

It's also rather subtle - depending on what actually happens when your site receives faulty input it may indeed turn out that the situation "Manipulated data with correct padding" causes your site to return a 404 or a redirect to a login page, while "Manipulated data with incorrect padding" causes your site to return a 500. If this is the case - well, once again the site is a 'Padding Oracle' and vulnerable.

So, while a custom 404-handler is not a problem as such, if it causes an attacker to be able to distinguish between errors caused by incorrect data with correct and incorrect padding...

So, everyone, do follow the instructions given even if they may in some cases overshoot.

It's really a very annoying situation and very hard to fix. I'm fairly sure there will be no magic patch to fix it all, but rather a patch to alleviate some situations along with some new directives about what to do and what to not do.

Update: (Sorry for the spamming, as usual part of the confusion comes from indadequate disclosure...). An oracle seems to be provided by WebResource.axd - the handler apparently will return a 404 when the padding is correct, but the resource is wrong, and a 500-error when the padding is incorrect.

Thus the attack seems to use the fact that a WebResource.axd call using a manipulated 'd' query string parameter may either return a 404 or a 500 - there's your padding oracle if this is the case.

There may be more attack vectors, but this is the one mentioned and it explains why and in what situations you are not allowed to tell your user the difference between a 404 and a 500.

The patch will likely adress this particular issue, but remember that there are many other situations that may provide an oracle!

It's really annoying that Microsoft does not do a full disclosure from start! After all, the original vulnerability has been known for 8 years, the original attack tool (not targeting ASP.NET) has been out for months! It's only the ASP.NET tweak that's new.

Yes, it is important to note that these configuration changes are not the final fix, this is the stopgap workaround to mitigate this problem until a software update is released by Microsoft.


As for it being hard to fix properly:
If they don't consider themselves allowed to change their design decisions even though it's essentially transient data that is produced and consumed by ASP.NET itself, then yes, it seems messy to shut the oracle up.

However, if they can change the scheme used for these things and add a MAC for the encrypted/padded data that can be validated first (this is what was proposed in the original paper 8 years ago) or use some other scheme that is not affected by this kind of problem then it would seem much more straightforward to fix this.

Updated information from Microsoft suggests that the workaround requires an additional workaround.

http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx

http://www.microsoft.com/technet/security/advisory/2416728.mspx

The fix seems to be underway:

http://blogs.technet.com/b/msrc/archive/2010/09/27/out-of-band-release-to-address-microsoft-security-advisory-2416728.aspx

An official patch is released:

http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx

Patch is now available on Windows Update

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx