http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

Now, if the detection tool reports that your apps are vulnerable, and the apps are public-facing (on the Web), you will really want to consider the workaround.

The emphasis of the workaround is to “homogenize the error codes”. The exploit relies on error codes returned by the application to an attacker. The more differentiated the error codes, the more it learns about the encryption, and the better chance it has on cracking the encryption (read-up on “Padding Oracle Attack”).

I created a stripped-down test ASP.NET Web application project that initially has customErrors=”Off”. Within the project, I created pages that will deliberately throw errors. I have a “Divide by Zero” page, a “Throw Error” page, a “View State Exception” page, and a link from the default page to a non-existent page. I used Fiddler to monitor the traffic to and from the app while customErrors=”Off”. Next, I apply Scott Guthrie’s ASP.NET workaround for this vulnerability. I set customErrors=”On” and initially, I use redirectMode=”ResponseRedirect”. The HTTP 500 response codes disappeared but there are still HTTP 302 (redirect) responses. See the evolution of the response codes as I changed the customErrors section:

customErrors=”On” starts at line 13 in the screenshot above. No more HTTP 500 once customErrors was turned on. However, there are still HTTP 302, which may clue-in the attacker that an error occurred and hence the redirect to a generic page.

So we change the customErrors element once more time. I set redirectMode=”ResponseRewrite”:

   

<customErrors mode="On" defaultRedirect="fatwhale.htm" redirectMode="ResponseRewrite" />

(By the way, in case you’re wondering what the “fatwhale.htm” page is, it is in reference to the twitter whale whenever twitter service gets overloaded.)

After setting redirectMode=”ResponseRewrite”, the traffic captured by Fiddler shows that everything is consistently HTTP 200, even though we know that run-time errors were occurring on the individual pages:

Scott responded to some of the comments in his blog post and he strongly encouraged people to homogenize the response/error codes. The Fiddler screenshots I showed above is what I think Scott Gu means by “homogenizing the codes”.

At this time we are not aware of any attacks using this vulnerability and we encourage customers to review the advisory for mitigations and workarounds.

Oh yeah, add the fact that the article starts with:

Today we released Security Advisory 2416728 describing a publicly disclosed vulnerability in ASP.NET that affects all versions of the .NET Framework.

If those lines don’t get your attention, I don’t know what will!

A detection script was made available also at the TechNet article “Understanding the ASP.NET Vulnerability”. The script is ran as a VBScript and will report all Web app configurations that are vulnerable. If your apps are not vulnerable, the script will report “OK” on the app. The report looks like the following:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Enumerating possible paths with ASP.Net configuration that have custom errors turned off.

C:\inetpub\wwwroot\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp1\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\2639\wpresources\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\4444\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp2\web.config: ok

If your app shows “Vulnerable configuration found”, then the Security Advisory is applicable for that app. You want to see “ok” like in the last line of the example above.

The vulnerability is called “Padding Oracle Exploit”. The attacker will attempt to send tampered data to the web server and the web server will generate error messages. As more error codes get returned to the attacker for the tampered requests, the attacker can learn what the encryption is. Once the encryption is compromised, the exploit beings. This vulnerability will allow an attacker to read data, even encrypted ones such as data stored in the View State, and even download files such as the web.config file from the target server. (But requests for web.config files cannot be served by IIS, right???) Scott Guthrie explains in his blog how this vulnerability works. Scott also explains how to workaround this issue. Before a patch or security update appears, this is the best tool against the exploit provided by Microsoft.

You say “But I never store sensitive information in the View State!” Well, read on. In the Microsoft TechNet Security Advisory (and even Scott’s blog post), the workaround’s main theme is homogenizing the error page. The TechNet security advisory says “Homogenizing errors is a crucial component to help protect against this attack.” This means turning customErrors to “On” and explicitly specifying the defaultRedirect page. For full details, please read Scott Guthrie’s blog post.

Now, you might say, this is just another over-hyped, exaggerated propaganda by the Microsoft haters. Well you can throw that argument out the window since it is Microsoft itself that is telling its customers about the vulnerability. There is also a Common Vulnerabilities and Exposure entry for this. The CVE entry says it just has a “candidate” status on it right now and may even be “rejected in the future”.  Is that grounds for ignoring it because it’s just a “candidate” CVE entry? Is it really worth ignoring because the probability and severity of the exploit has not been fully established yet? For public-facing sites, I recommend you implement the workaround as soon as possible. The workaround is fairly cheap to implement—just do it! There will be many apps that will be fine and no workarounds would be necessary (their customErrors configuration is already protected against this exploit). But if the detection tool above says “vulnerable” on your site, and the site is public facing, all I can say is “Wow!” should you decide to ignore it.

What the heck?? You thought you were admin! You check the Farm Administrators list and your account is there. So, what gives??

Windows User-Access-Control is getting in the way. Although your account is Farm admin, because of UAC, you’re still not permitted to do stuff in Central Admin like create new Web apps. The fix? Disable UAC and reboot Windows. After reboot, you should be able to create new Web apps:

Caution: after you have created your Web apps and Site collections in Central Admin, turn on the UAC again and reboot. Turning off UAC for good is not recommended even if it’s annoying.  If you permanently turn off UAC, malware might have a chance to install in your PC (you are admin, no prompts for system mods—yikes!!)