Try our conversational search powered by Generative AI!

Per Ivansson
Sep 20, 2010
(3 votes)

Security Vulnerability in ASP.NET

Last week on Wednesday the 15th, EPiServer was alerted of a security vulnerability in Microsoft ASP.NET. We also learned that the details would be made publically available on a security conference in Argentina by two researchers on Friday later that week. Due to the indicated seriousness of the vulnerability, we made the investigation of this our top priority within the development department and on Thursday we could confirm that the exploit really existed as described. The vulnerability is in the ASP.NET encryption mechanism and parts of the exploit lie in how error messages are returned by the .NET Framework.

We acted according to our set processes in a situation as this and communicated with the main contacts at our partners so that they received relevant information about the matter. This was done well before the public announcement was made at the conference. EPiServer’s proposed workaround was more or less identical to the one announced by Microsoft later Friday evening, but with some additions. For more information regarding the vulnerability and the workaround, please read:

We advice everyone to take this threat very seriously and act accordingly.

Sep 20, 2010


Sep 21, 2010 10:15 AM


Sep 21, 2010 10:33 AM

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?

Sep 21, 2010 10:33 AM

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:

Sep 21, 2010 10:33 AM

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?

Sep 21, 2010 10:33 AM

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"

Robert Hubinette Hubinette
Robert Hubinette Hubinette Sep 21, 2010 10:33 AM

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:

read especially step 5+6

Sep 21, 2010 10:33 AM

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.

Svante Seleborg
Svante Seleborg Sep 21, 2010 10:33 AM

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 .

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...

Sep 21, 2010 10:33 AM

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.)

Svante Seleborg
Svante Seleborg Sep 21, 2010 10:33 AM

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.

Svante Seleborg
Svante Seleborg Sep 21, 2010 10:33 AM

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.

Sep 21, 2010 11:19 AM

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.

Sep 27, 2010 10:08 AM

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

Sep 27, 2010 11:07 PM

The fix seems to be underway:

Sep 28, 2010 10:55 PM

An official patch is released:

Oct 4, 2010 12:57 PM

Patch is now available on Windows Update

Please login to comment.
Latest blogs
Migrate Catalog content properties

A colleague asked me yesterday – how do we migrate properties of catalog content. There is, unfortunately, no official way to do it. There are...

Quan Mai | Feb 20, 2024 | Syndicated blog

Adjust log levels in Optimizely DXP

You may adjust the log levels for your site in Optimizely DXP yourself, but only for the Integration environment. Follow this step-by-step guide.

Tomas Hensrud Gulla | Feb 20, 2024 | Syndicated blog

Introducing Search & Navigation Dashboard for Resource Usage

We're excited to unveil the latest addition to the Search & Navigation suite: a dashboard designed to proactively monitor your resource usage. It's...

Edvin Dackelid Johansson | Feb 20, 2024

Introducing Jhoose Security Module V2.0

Version V2.0 of the Jhoose Security module has been released and is available via the Optimizely nuget feed. This update not only squashes several...

Andrew Markham | Feb 19, 2024 | Syndicated blog