ASP.NET security vulnerability makes Sitefinity vulnerable

ASP.NET security vulnerability makes Sitefinity vulnerable

Posted on September 20, 2010 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

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"/>
</customErrors>


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();

      prng.GetBytes(delay);
      Thread.Sleep((int)delay[0]);
        
      IDisposable disposable = prng as IDisposable;
      if (disposable != null) { disposable.Dispose(); }
    }
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        An error occurred while processing your request.
    </div>
</body>
</html>

Step 3:  Test the fix

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

http://www.sitefinitywatch.com/WebResource.axd?d=8KdqlbnKlEkJNojRMjxtSxbXkp67u-rzhy_VoqsYA901&amp;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.

progress-logo

The Progress Team

View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments

Comments are disabled in preview mode.
Topics

Sitefinity Training and Certification Now Available.

Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.

Learn More
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

Loading animation