iFinity Blogs 

Fixing ASP.NET Security Vulnerability in a DotNetNuke Install

by Bruce Chapman on Monday, September 20, 2010 4:19 PM

Scott Guthrie posted about an important ASP.NET security vulnerability over the weekend.  If you have a DotNetNuke website, this vulnerability affects you, so take the time to read this and check if your site might be affected.

So far there has been no patch for the operating system, but there is a workaround which is very simple.

Basically, the vulnerability is that malicious users can probe your site and, from certain error codes, can break the cryptography securing important files like your web.config file.

The fix involves updating your website to provide a generic error page for all server errors.  Many people will already have such a setup in place, although others (like me) might have left more descriptive error messages switched on for working out what has gone wrong.

Update [21st September] : DotNetNuke has an official post out on this one, so I think take a look at the official word on this one.  See here : ASP.NET Security Vulnerability workaround for DotNetNuke sites.

Note that in my solution I don’t implement the random timing.  I’ve now read up more on this, particularly from this helpful post by Troy Hunt.   I understand the need for random timing more, and it should be part of your workaround.

Also, this affects people using the custom 404 error handling functionality in Url Master 2.0.  From my understanding of the security vulnerability, I’m recommending that you switch this feature off until more information is known.   For Url Master 2.x installations, I recommend implementing the changes as posted in the DotNetNuke blog post (linked above) and then switch your 404 Handling to ‘Use Default ASP.NET 404 Handling’.

How to implement the vulnerability workaround in your DotNetNuke Installation

Step 1 : Obtain your web.config file and make a copy of it

Step 2 : Open up the web.config file in a text editor (notepad will do) and search for the <customErrors> section.

Step 3 : Update the customErrors section, so that all errors will be redirected to a common error page.  You will need either of these two entries:
ASP V1.0 to V3.5



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



ASP 3.5 SP1 and ASP.NET 4.0



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



Note that if you aren’t sure, use the first (ASP.NET 1.0 to 3.5) version.

Step 4 : Save and upload your web.config back to your website


This method changes the custom error handling of your DNN site to use the in-built DNN error page.  This prevents malicious users from obtaining specific error information from your server, as all errors will show a generic error page.


Extra : Modify the standard DotNetNuke Error Page to customise for your site

One of the issues with showing the standard DNN error page is that it’s branded for the dotnetnuke.com site.  If you don’t want this, I suggest downloading the ErrorPage.aspx (and ErrorPage.aspx.vb) files, and changing them for your own use.

I don’t usually advise changing any core files, since any DotNetNuke upgrade will overwrite your changes.  In this case, it’s trivial to do and you can just keep a copy of the file ready to re-upload whenever you upgrade your install.

Here’s the changes I have made:

ErrorPage.aspx : Line 15

<asp:Image ID="Image1" runat="server" ImageUrl="~/portals/0/ifinity-logo.gif" BorderStyle="None" AlternateText="iFinity Software" />

The changes are highlighted in bold : it replaces the standard DotNetNuke logo with the site logo, and the Alt Text for that image.  Note you’ll have to locate where your site logo file is for your site.

ErrorPage.aspx : Line 19

<h2>Website Error</h2>

I have changed ‘DotNetNuke Error’ to ‘Website Error’.


The result is shown above.

If you run a multi-portal installation, you may want to dial it back a step further and remove the logo altogether.  This same error page will be used for all portals on the installation.

You can also add things like support contact information, or even some humorous pictures.  It’s just a plain old Html page after all.

Blogs Parent Separator Crafty Code
Bruce Chapman

The craft of writing code. The outcomes from being crafty with code. Crafty Code is tales from the coding bench.

2 comment(s) so far...

Anonymous 9/20/2010

Hi Bruce,<br><br>I appreciate your help in getting the word out to the DotNetNuke community! I wanted to take a moment to point out two potential concerns with the text above:<br><br>1. For anyone unaware of their current .NET framework version, it is important to try the 3.5 SP1+ instructions FIRST; the defaultRedirect attribute is a critical component in these installations, and I would not want anyone to feel protected but nonetheless omit it. If the attribute causes an application failure, one may fall back to the pre-3.5SP1 metadata. It is best, of course, to identify the framework version first rather than making any assumptions.<br><br>2. The configuration described above does not include a cryptographically randomized delay in HTTP response. While this delay may not be in direct response to a timing side channel attack (even fully entropic delays may be weak against the law of large numbers), it could also serve to increase the time in which a prober consumes in identifying vulnerable sites. Since the full set of oracles has not yet been made publicly available, I would recommend that all installations use the exact error page provided by Microsoft (linked to in the blog entry). <br><br>Hope this helps!<br><br>Brandon

Bruce Chapman 9/20/2010

@brandon - my take from the blog post was that the timing delay was optional - the main thing was to return a generic error message.<br><br>It's possible to include the timing delay from Scott's original post, all you would need to do is incorporate the loop into the error.aspx.vb page, or, as you point out, just use the entire solution posted.<br><br>I stand corrected on the order in which to try the items. Now that I think about it, including the later version is unlikely to create a broken install, which is what I was concerned about (hence my thoughts to try the simpler version first). As you state, it's easy to revert back if it's broken, though in my experience many panic if faced with a broken install.

Bruce Chapman
Hi, I'm Bruce Chapman, and this is my blog. You'll find lots of information here - my thoughts about business and the internet, technical information, things I'm working on and the odd strange post or two.
Connect with Bruce Chapman on Google+

Share this page
Get more!
Subscribe to the Mailing List
Email Address:
First Name:
Last Name:
You will be sent a confirmation upon subscription

Follow me on Twitter
Stack Exchange
profile for Bruce Chapman at Stack Overflow, Q&A for professional and enthusiast programmers
Klout Profile

Page Tags