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.
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).
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.
This is an information disclosure vulnerability. An attacker who successfully exploited this vulnerability could read data, such as the View State, which was encrypted by the server. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce useful information that could be used to try to further compromise the affected system.
More from Microsoft:
How does this relate to Windows Home Server? Well, if you run the detection script against the Remote Access sites, you get:
c:\inetpub\home\web.config: ** Vulnerable configuration found **
c:\inetpub\upnp\web.config: ** Vulnerable configuration found **
C:\inetpub\intranet\web.config: ** Vulnerable configuration found **
C:\inetpub\Enroll\web.config: ** Vulnerable configuration found **
C:\inetpub\EnrollId\web.config: ** Vulnerable configuration found **
Intranet, Enroll and EnrollId failing the check isn’t terrible; those sites run on port 55000 and are used by clients inside the network. As long as you don’t allow incoming connections to WHS through your firewall on port 55000, an attacker would have to be inside your network to exploit these web applications. Home and Upnp are accessible externally with the default WHS Remote Access configuration, however.
We’re not talking about IIS error responses here, only responses generated by an ASP.NET web application. Windows Home Server uses IIS 6, because it’s based on Windows Server 2003, and a number of errors are handled in IIS before they even make it to the Remote Access web application (404 File Not Found, for example).
This exploit isn’t the end of the world for our publically accessible Windows Home Server Remote Access sites; an attacker can only download files that are within the compromised web application (i.e. within c:\inetpub\home\), and can’t arbitrarily access files in other locations on the server. The Home and Upnp applications don’t contain sensitive information in their configuration files, unlike most ASP.NET web applications that have a back-end database.
However, just to be on the safe side, I’ve edited web.config in the Home and Upnp web applications on my production server to include the recommended work-around for the exploit. Neither of these web applications have a custom error page, so I’ve just set the defaultRedirect to the default page for each application.
Web.config for Upnp now looks like this:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="welcome.aspx" />
<trace enabled="true" requestLimit="100" pageOutput="false" traceMode="SortByTime" localOnly="false"/>
<globalization requestEncoding="utf-8" responseEncoding="utf-8"/>
And for Home:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="default.aspx" />
<trace enabled="false" localOnly="false" pageOutput="false"/>
Because Windows Home Server has .NET 3.5 SP1 pushed via Windows Update, I also added the 3.5 SP1-specific configuration for customErrors to web.config in Remote as well:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="error.aspx" />
Note the redirectMode setting.
There is another component of the work-around that waits for a random time interval before responding with an error message. This helps to prevent an attacker from guessing which error occurred based on the time it took to get to the error page. If you’re concerned about exposure, then you can implement the custom error page from this article, instead of redirecting to an existing page as I have above.
Microsoft have said that a real fix for this issue is in the works. I’d expect it to show up on Windows Update pretty shortly; there are a lot of ASP.NET web sites out there that don’t implement custom error handlers and are probably quite vulnerable. If you’re a developer, go check all your ASP.NET sites and applications now – you do not want to be caught by this one.