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