Major ASP.NET Forms Authentication Vulnerability Found

You probably haven't heard about this yet, but there is a serious ASP.NET Forms authentication vulnerability that has been reported and is starting to make its way around the Internet. I have refrained from posting about it in an effort to wait for Microsoft to handle it, but now that its creeping out to blogs, I thought I better speak up so admins get a chance to cut through the FUD and deal with the real issue.

The vulnerability was originally reported on NTBugtraq on September 14th by Toby Beaumont. I won't go into the politics of this report too much, but would like to point out a few things that bothered me about this report. First off, I am one for fair disclosure for vendors. I think Toby was wrong in blasting this on a major security mailing list without first letting Microsoft know (that is what secure@microsoft.com is all about). He even admits this at the end of the post, and I think that this is somewhat irresponsible. Secondly, I think Russ should have known better that to post it on his list (he does moderate every post after all) without giving Microsoft some time to look into this. Anyways, I could go on and whine about this forever, but will instead just accept that the information is out and move on.

Now to details about the vulnerability. The basic premise behind the bug is that a specially crafted URL string can bypass the expected authentication model invoked in .NET forms authentication. The original report discusses how by using a backslash where a front slash is expected, the parser dealing with the pathing chokes. This seems to be a problem in how System.Web.Security.FormsAuthentication uses the value provided in the variable "Context.Request.Path" to validate its internal representation of the web.config(s) Form Authentication mappings. For more information on this you can check out the research Dinis Cruz has done on this.

Now who is and is not affected? This vulnerability has been reported to work on all operating systems pre-W2K3 supporting IIS5, including W2K, SBS2000 and XPSP2. W2K3 is NOT affected since it is using IIS6. In IIS6 Microsoft rewrote the parser doing path normalization and it seems to currently be resilient to this attack vector. This means that for us up to date SBSers, we are safe since SBS 2003 is based on the same W2K3 code base... and we are using IIS6.

How can you fix this? Currently Microsoft hasn't even acknowledged the vulnerability exists. In the meantime if you are vulnerable you may wish to look at the upgrade path to W2K3 / SBS2K3. You really should be doing this anyways; the attack surface of the W2K3 server platform is considerably smaller and a lot of these issues have been addressed. If that is not feasible, you really should install URLScan and run the IIS Lockdown Wizard. Read knowledge base article 815155 to learn how to configure URLScan to protect your ASP.NET web application.

There is some code floating around the Internet from Duncan Godwin in an attempt to temporarily fix this using HttpModule and RewritePath. I would caution you in using this code. Although it DOES address the symptom, IT IS NOT THE CURE. Duncan wrote a neat hack that will check and rewrite paths if a backslash exists when it shouldn't. He even was smart enough to add a check for a UTF-8 encoded representation using %5c instead of using a backslash ('\'). However, this can simply be defeated by using double escaping representation.

One of the problems with URL encoding is the fact you can really nest double escaping pretty deep. %5c represents a backslash character. But so do these:

• %255c (%25 which is the escape for % followed by 5c)
  
• %%35%63 (The % char followed by %35, which is the escape for 5, and %63 which is the escape for c)
  
• %25%35%63 (The escapes for all three chars)
  

As you can see, the escapes can nest pretty deep. As such, Duncan's code won't actually stop the problem.

To really get around this problem, I think the only way this will be done properly is to reduce the URL string to its canonical form by using something like the Win32 API MultibyteToWideChar. This would ensure that it won't be hidden in escape nesting hell. However, I currently don't have time to write some code to address this, and will need to rely on other developers who work closer in the ASP.NET arena to do so. You will need to P/Invoke this I'm sure, but that shouldn't be too hard.

There are several people doing some more research on this that you should watch. Some of the latest information seems to be coming from Dominick Baier and can be read here. What we currently know is that the latest version of .NET did not address this, and that it continues to be vulnerable on all platforms running IIS pre-WS2K3.

fritz wrote a quick proof of concept web app which you can download and try to see if you are vulnerable. If you think you may be at risk, I suggest you check it out and see for yourself.

Good luck.

Posted by SilverStr at October 2, 2004 11:38 AM | TrackBack