Yesterday, I blogged about the newest ASP.NET Vulnerability. As of this writing, there is still no patch for the ASP.NET Security Advisory 2416728. If the detection tool as part of the workaround provided by Microsoft reports that your apps are okay, then you don’t have nothing to worry about—just wait for the security update (what else can you do?).
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”.
Correction on the second screenshot: it’s redirectMode=”ResponseRewrite” and not ResponseRedirect.
Re the “what else can you do” – plenty of things.
Check out pentonizer’s blog for some other config things that can help making asp.net apps more secure:
http://pentonizer.com/general-programming/aspnet-poet-vulnerability-what-else-can-i-do
Also, if you have an intrusion detection device, I think there may be ways to detect when there’s a flood of requests sent to webresource.axd etc and block such traffic. (The reason for that would be that one of the people behind the POET exploit tool says that just masking http errors is not enough – http://twitter.com/thaidn/status/24832350146 )… I don’t know if that is true or not, but the more layers of security you can have the better…
Finally, keeping an eye on web server logs and the windows event log may reveal ongoing attacks. I wrote a small experimental windows service that keeps an eye on the event log, looking for warnings containing the exception that is supposedly generated by POET attacks… …more on that in my blog:
http://huagati.blogspot.com/2010/09/installing-poet-sniffer-service.html
This is SOOOO bad for SEO though. If it is important to you you should be using a custom error HttpModule to change all 4**-5**’s to a similar status code. Like 500 say. returning 200 for a 404 is awful. Google will index them all AND will take them as duplicate content.
Unless Microsoft’s plan is to destroy Google’s indexing algorithms… Hmmmm…..
@KristoferA: yes, I agree that you need to do more in order to protect the ASP.NET apps. I wanted to share what tests I was doing in order to confirm that I did my job protecting the ASP.NET apps. Nice screenshot of the Juliano Rizzo advocating your windows service! I’ll look into it when I get a chance. I’ll tweet the link to your POET attack detection service too. I really wish I was more of a hacker (white-hat) so that I can perform the exploit and see what it can really do and then apply the “workarounds” and try to hack the apps again only to fail. I wish my tests were something like that instead of just looking at the HTTP response codes.
@British Developer: yep, bad for SEO. You know what else is bad? It’s bad for UX too. Because of the workaround, the user is denied useful information of what went wrong (if things go wrong). It should be temporary though, until the security update comes out.