Sep 18

Posted by: cathal connolly
Saturday, September 18, 2010 5:55:00 PM 

Background
A critical serious vulnerability in asp.net was publically disclosed late Friday at a security conference.  We recommend that all users immediately apply a workaround (described below) to prevent attackers from using this vulnerability against your DotNetNuke (and any other ASP.NET) applications.

We initially became aware that of the potential existence of this issue on Tuesday and reached out to the two researchers involved, who responded and made us aware that it was an asp.net issue and that they had successfully used it against a DotNetNuke install and intended to demonstrate that during a conference on Friday 17th September. They also confirmed that original reports that changing the encryption scheme in the web.config of asp.net websites were incorrect and did not stop their exploit.

The DotNetNuke security team immediately began to read all the available material on this and similar oracle padding attacks and considered potential mitigations we could create. In addition we reached out to our contacts in the asp.net team and the Microsoft Vulnerability Research (MSVR) team to let them know the additional information we had and to ensure that we would hear about any further details or workarounds they determined.

Immediately after the first public demonstration of the bug (and a related video demonstration), Microsoft determined a workaround that will protect asp.net sites (including DotNetNuke sites), whilst they work on a more permanent solution - likely a server patch to resolve this at the machine/framework level.

Determining framework version
There are two separate workarounds dependant on the .net framework version a website is using, so it's important that before applying the workaround you determine the correct version to use.

Getting framework version from DotNetNuke
To determine the version of the .net framework a DotNetNuke site is running against, please log in as host and go to host->host settings. The version will be shown under the .net framework field e.g. in this site DotNetNuke is running under .net 2.0 and should use the first version of the fix.

 
And in this site DotNetNuke is running under .net 3.5 and should use the 2nd variant of the fix.


 

Getting framework version from IIS
If you have access to internet information server (IIS), please open it and expand out the "Application pools" node. This will display a list of available application pools and their .net framework version.

If you're unsure what application pool your website is using, select the website in IIS, and then click the "Basic settings" link - a screen similar to this will appear:


 
Note: Clicking the select button will open up the application pool dialog which also contains the framework version e.g.


Getting framework version from the web.config
The version of the framework in use is also shown in the web.config file. The value is in a number of locations, but the most obvious will be the node. If it's using .net 3.5 or higher it will contain a number of entries that reference that e.g.

Applying the workaround

Note: The following is extracted from the blog at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0, or ASP.NET 3.5 then you should follow the below steps to enable and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the section of the web.config file to have the below settings:

3) You can then add an error.html file to your application that contains an appropriate error page of your choosing (containing whatever content you like).  This file will be displayed anytime an error occurs within the web application.

Notes: The important things to note above is that customErrors is set to “on”, and that all errors are handled by the defaultRedirect error page.  There are not any per-status code error pages defined – which means that there are no sub-elements within the section.  This avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure.

Enabling the Workaround on ASP.NET V3.5 SP1 and ASP.NET 4.0

If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you should follow the below steps to enable and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the section of the web.config file to have the below settings.  Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0:

3) You can then add an Error.aspx to your application that contains an appropriate error page of your choosing (containing whatever content you like).  This file will be displayed anytime an error occurs within the web application.

Note: we highly recommend you read both the Microsoft advisory http://www.microsoft.com/technet/security/advisory/2416728.mspx and Scott Guthries blog for further details http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx and for an example of the error.aspx page.

What happens now?
We've already taken steps to protect our DotNetNuke properties to ensure that they're safe, and to ensure that no user data could be accessed. We've put together an action plan to push this message out as widely as possible, and the development team are working on a fix that we can include in the forthcoming 5.5.1 as well as a solution for people who cannot upgrade quickly for some reason, and are not confident about applying the manual workaround. We'll release more details once we have them.

*** Update - Monday 20th September ***
We've receieved a lot of emails about this so I thought I'd answer a few of the common questions about the Microsoft Oracle padding security issue:

• Is this a DotNetNuke specific issue? No, it’s a problem in all versions of asp.net, so you’ll want to update all your asp.net sites. It’s also not webform specific, so please fix your ap.net mvc sites. Finally, it’s also easy to forget some less obvious asp.net sites so be sure to patch all your sharepoint, outlook web access and team foundation server sites.

• Can i keep my existing custom 404 page? No, the workaround requires all HTTP exceptions to be redirected to the same page. We recommend commenting out any error status code lines so you can revert to them once Microsoft have provided a more permanent fix - 5.5.1 will automate this part.

• Is the default DotNetNuke web.config secure enough , i’ve read that RemoteOnly is enough to stop this attack? No, it’s not enough to use RemoteOnly (or On) – you need to redirect all the http exceptions to the same file to foil the padding attacks

• I read that changing to 3DES protects against this, is that true? No, it’s not, the attack does not depend on the ciphertext itself, so the encryption method used is irrelevant.

• The Microsoft advisory suggest creating an error.aspx page, but i know DotNetNuke has one - is that ok to use? Theoretically it’s fine to use as it fulfils the first aim of the workaround, that of redirecting all errors to one page. However, this type of attack also commonly utilises timing as a side channel (http://en.wikipedia.org/wiki/Side_channel_attack). The Microsoft error.aspx page also adds a small time delay to further obfuscate this. Currently we’d recommend creating a file using the Microsoft example code. As part of 5.5.1 we will be updating our errorpage.aspx, so it can be reused.

• Is this a permanent fix? No, it’s just a short-term workaround, and does mean that sites temporarily can’t run with custom pages for http exceptions (such as custom 404 pages). It’s expected that MS will have a security patch that can be deployed to resolve this correctly, allowing sites to revert to their previous customErrors settings.

*** Final update ***

• Subsequent to the previous update, Microsoft and other security researchers realised that there were additional variants on the attack that could be used. At least one of these could not be protected via any workaround. The only valid fix for this is to install the security patch that Microsoft created to fully resolve it. This patch will be automatically deployed as a Windows Update as part of the September patches, and will resolve this issue for all versions of the .net framework on the machine (i.e. it is a server level fix, not a site level fix). Further details can be read at http://www.microsoft.com/technet/security/bulletin/ms10-sep.mspx