| ASP.NET Security Vulnerability workaround for DotNetNuke sites |
 |
|
A few hours ago we released a Microsoft Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET.
This vulnerability was publically disclosed late Friday at a security conference. We recommend that all customers immediately apply a workaround (described below) to prevent attackers from using this vulnerability against your ASP.NET applications.
What does the vulnerability enable?
An attacker using this vulnerability can request and download files within an ASP.NET Application like the web.config file (which often contains sensitive data).
At attacker exploiting this vulnerability can also decrypt data sent to the client in an encrypted state (like ViewState data within a page).
How the Vulnerability Works
To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.NET which acts as a padding oracle. This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server. By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.
How to Workaround The Vulnerability
A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page - regardless of the error encountered on the server. By mapping all error pages to a single error page, you prevent a hacker from distinguishing between the different types of errors that occur on a server.
Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page. This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.
Enabling the Workaround on ASP.NET V1.0 to V3.5
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 <customErrors> 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 <customErrors> section of the web.config file to have the below settings:
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</configuration>
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 <error> sub-elements within the <customErrors> 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 <customErrors> 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 <customErrors> 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:
<configuration>
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
</system.web>
</configuration>
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.
4) We recommend adding the below code to the Page_Load() server event handler within the Error.aspx file to add a random, small sleep delay. This will help to further obfuscate errors.
VB Version
Below is a VB version of an Error.aspx file that you can use, and which has a random, small sleep delay in it. You do not need to compile this into an application – you can optionally just save this Error.aspx file into the application directory on your web-server:
<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
Sub Page_Load()
Dim delay As Byte() = New Byte(0) {}
Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
prng.GetBytes(delay)
Thread.Sleep(CType(delay(0), Integer))
Dim disposable As IDisposable = TryCast(prng, IDisposable)
If Not disposable Is Nothing Then
disposable.Dispose()
End If
End Sub
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
Sorry - an error occured
</div>
</body>
</html>
C# Version
Below is a C# version of an Error.aspx file that you can use, and which has a random, small sleep delay in it. You do not need to compile this into an application – you can optionally just save it into the application directory on your web-server:
<%@ 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>
How to Verify if the Workaround is Enabled
Once you have applied the above workaround, you can test to make sure the <customErrors> section is correctly configured by requesting a URL like this from your site: http://mysite.com/pagethatdoesnotexist.aspx
If you see the custom error page appear (because the file you requested doesn’t exist) then your configuration should be setup correctly. If you see a standard ASP.NET error then it is likely that you missed one of the steps above. To see more information about what might be the cause of the problem, you can try setting <customErrors mode=”remoteOnly”/> – which will enable you to see the error message if you are connecting to the site from a local browser.
How to Find Vulnerable ASP.NET Applications on Your Web Server
We have published a .vbs script that you can save and run on your web-server to determine if there are ASP.NET applications installed on it that either have <customErrors> turned off, or which differentiate error messages depending on status codes.
You can download the .vbs script here. Simply copy/paste the script into a text file called “DetectCustomErrors.vbs” and save it to disk. Then launch a command window that is elevated as admin and run “cscript DetectCustomErrors.vbs” to run it against your local web-server. It will enumerate all of the applications within your web server and verify that the correct <customErrors> configuration has been specified.
When it comes to DNN here is what you need to do:-
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.
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 <assemblies> node. If it's using .net 3.5 or higher it will contain a number of entries that reference that e.g.
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
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 <customErrors> 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 <customErrors> section of the web.config file to have the below settings:
<configuration> <system.web> <customErrors mode="On" defaultRedirect="~/error.html" /> </system.web> </configuration>
<customErrors mode="On" defaultRedirect="~/ErrorPage.aspx" />
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 <error> sub-elements within the <customErrors> 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 <customErrors> 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 <customErrors> 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:
<configuration> <system.web> <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" /> </system.web> </configuration>
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?
DNN Corp and most of us during the weekend, have 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.
Please check here or dotnetnuke.com for further news on this.
|
|
|