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
3. Select Web Form
4. Type error.aspx for the filename
5. Unselect Place code in separate file
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:
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.