More in this section
Blogs RSS feed

ASP.NET security vulnerability makes Sitefinity vulnerable

by Gabe Sumner

Late last week an ASP.NET security vulnerability was disclosed.  Since that time Microsoft has issued a Security Advisory and Scott Guthrie published a blog post describing how to prevent this exploit.

Sitefinity 3.x uses the ASP.NET technologies that are vulnerable to this exploit.  Consequently, Sitefinity is made vulnerable by this exploit.  It is strongly recommended that all Sitefinity customers apply the solution described in Scott Guthrie’s blog post to their Sitefinity web site(s). 

Below, I’ll demonstrate how to apply this fix to a Sitefinity web site:

Step 1:  Enable CustomErrors

The exploit uses the errors reported by ASP.NET to eventually decrypt data.  As a result, part of the solution to this exploit is to prevent ASP.NET from sending its default error messages.  To do this we’ll configure a custom error page (ASPX page) that will handle displaying error messages.  To do this:

1.  Open the ~/web.config for your Sitefinity 3.x web site.

2.  Locate the <customErrors> section.

By default,  the <customErrors> section should look like this:

<customErrors mode="RemoteOnly">
  <error redirect="~/Sitefinity/nopermissions.aspx" statusCode="403"/>

For web sites using using ASP.NET 2.0 – 3.5, this section should be modified as follows:

<customErrors mode="On" defaultRedirect="~/error.aspx" />

For web sites using ASP.NET 3.5 SP1 – 4.0 (Sitefinity 3.7 SP4) this section should be modified as follows:

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />

This configuration instructs ASP.NET to use a custom error.aspx page for all ASP.NET errors. 

Please note: this configuration also breaks Sitefinity’s ability to redirect to the login page if a user accesses an unauthorized page.  There might be workarounds for this.  However, in the interest of circulating this news quickly, I’m publishing the information I currently have.

Step 2:  Create a Custom Error page

Below are the instructions for creating the custom error page referenced in the configuration above:

1.  In Visual Studio, right-click the web site project.

2.  Click Add New Item

Adding a new item to a Sitefinity web site in Visual Studio

3.  Select Web Form

4.  Type error.aspx for the filename

5.  Unselect Place code in separate file

Create an error.aspx web form in Visual Studio

6.  Click the Add button.

7.  Paste the following code into the error.aspx page:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
   void Page_Load() {
      byte[] delay = new byte[1];
      RandomNumberGenerator prng = new RNGCryptoServiceProvider();

      IDisposable disposable = prng as IDisposable;
      if (disposable != null) { disposable.Dispose(); }

<head runat="server">
        An error occurred while processing your request.

Step 3:  Test the fix

To ensure this fix works, make an invalid request to your web site.  Here is an example:;t=634200755509128189

This URL won’t result in a 404 (file not found), but it will result in an ASP.NET error.  The error.aspx page creates a small delay and then displays a generic error message.  My understanding of this exploit isn’t very complete but it sounds like the delay does more to prevent the exploit than the custom error. 

If you’re interested in more details, read Troy Hunt’s wonderful blog post on this subject.  Please modify your Sitefinity web sites to implement this protection.  We’ll publish more information as it becomes available!


Update:  Sitefinity 4.0 is not vulnerable to this attack.  I’ll publish more information about this later.  However, it is partially irrelevant since there are very few (if any) production Sitefinity 4.0 web sites.


Leave a comment
  1. Josh Sep 20, 2010
    I've spent the better part of the day reading up on this... it's FASCINATING, but alarming. 

    thanks for posting this fix, but one thing I've not been able to understand is why introducing a delay in the error page works, why does it?

    how does this affect custom error (404) pages?
  2. Bob Sep 21, 2010
    In AES algorithm the encrypted text is padded to fit certain size. The exploit works by sending encrypted strings to the server that were encrypted with some random key. So the server will always return an error that the string cannot be decrypted. However, if the server returns different error when the padding of the encrypted string is correct and when not, it is possible to figure out the real encryption key by continuously modifying the string and sending it to the server. The process takes tens of thousands requests to complete.

    That’s why even slight delay in the responses can take ages to complete. Also if the error returned is always the same the exploit won’t know when the padding is correct.
  3. Tim Sep 21, 2010
    Hmm I am worried about this as our site is being attacked and has been for the last few days but is not a continuous attack a bot is making a webresource.axd  request every minute for an hour or so then backing off before trying again. I have implemented the interim patch but by my understanding acknowledging any response to an error in anyway means that eventually they will be successful. We are on 3.5 so have to use this custom error config :
    <customErrors mode="On" defaultRedirect="~/error.aspx" />
    Which still alerts the attacker that an error is thrown even though I return status code 200 ok, am I correct?

    Any thoughts?
  4. Georgi Sep 21, 2010

    The setup you have now is the correct one. You are right that an error is returned, but the point here is that the same error is returned for every request made by the bot. In other words, the request made by the attacker does not give him any valuable information.

    I would suggest that you monitor the web site for a couple more days until Microsoft releases the Asp.Net patch, and block the ip addresses from which the bot requests to the webresource files come.
  5. syed Sep 21, 2010
    how can i add a sleep script in my template which used by other page also
  6. Will Sep 21, 2010
    Thanks for the blog post. I check more frequently than any other tech site, so this provided a much needed heads up. I'm glad to see how this impacts Sitefinity specifically. I have some questions but I will post in the forums.
  7. Georgi Sep 21, 2010

    The workaround suggested is not specific to Sitefinity, so there are no differences in the code that you should add. Just add it to the page_load event, in the code-behind of your template. 

  8. David Sep 22, 2010
    Hi all,  I end up creating a master template for my errors, with the delay on the page load.  Hopefully that will help until I we can update the web.config for the redirect.
  9. Abraham Sep 27, 2010
    This solution patches the discovered vulnerability, but what about the future?  Does Sitefinity have some sort of best practices guide for security?  Do you have a notification list that we can subscribe to?
  10. David Sep 28, 2010
    Get the word out!

    A new Security Update has been release by Microsoft.  This update addresses the POET attack on Web Sites and should prevent a successful attack. 



  11. Anwar Sep 30, 2010
    Stack trace is a vulnerability pointed at the following blog
    Any security risks associated with webresource file .axd.
  12. escort girls Cannes May 21, 2013
    How do I start a blog under a pen-name and maintain my anonymity. How do you then get regular readers?
  13. Tanner Brockwell Aug 27, 2014

    Do you know if this effects Sitefinity 4.1.1501.0 SE ? It seems this depends on an OS exploit that MicroSoft patched.

    Sorry for the late comment, re mediating some old websites!

    Leave a comment