Alert – ASP.NET Security Issue and Guidance RRS feed

  • Question

  • User-2031965490 posted
    A note from the Microsoft ASP.NET Team: This alert is to advise you of the availability of a web page that discusses an investigation Microsoft is currently conducting into public reports of a security vulnerability in ASP.NET. A malicious user could provide a specially-formed URL that could result in the unintended serving of secured content. This alert is also to advise you of the availability of a new Microsoft Knowledge Base article: 887459. This article contains prescriptive guidance with steps customers can implement on their ASP.NET applications to help protect against a wide variety of malformed URL attacks. Microsoft is providing this prescriptive guidance in order to inform customers as quickly as possible about the vulnerability and information on how to prevent an attack. Microsoft is actively investigating this issue and plans to release additional guidance and a security update to remedy the issue as soon as possible. The Microsoft Knowledge Base article can be viewed here: http://support.microsoft.com/?kbid=887459 The web page that discusses the current investigation into the public reports of a vulnerability in ASP.NET can be viewed here: http://www.microsoft.com/security/incident/aspnet.mspx If you have any questions, please reply to this thread. Thank You, The Microsoft ASP.NET Team
    Tuesday, October 5, 2004 10:15 PM

All replies

  • User-1135537543 posted
    I guess I would like to know more about this, this is all pretty vague. All the links and everything are just vague. They don't tell you squat really about this. I mean does this allow anyone to download anythng from your site. Like web.config, compiled dll's and so on, or is this like if someone supplied a crafted URL to download some text document in some other folder on the website that is securect by NT security which could be feasable since the asp.net account needs access. Or can they access things from the directory below the root of the web. I mean if they can not force download of protected files. Like dll's .configs and files outside the web then well no big deal for a lot of us. I would think the classic asp source code download vulnerability which still exists in IIS 6 or lower that is not running asp.net would be much worse than this where Yes you can download an .ASP Page raw source code but for some reason regiis fixes this hole. So I am guessing by all the publicity and alerts that this can download anything on the server? including anything in the bin directory, or am i mistaken?
    Wednesday, October 6, 2004 10:18 AM
  • User1923083492 posted
    And how would you download the source of an asp-file from a w2k3/iis6 server? That hasn't been a vuln since the mid-90's. Isn't it just because you haven't registered any isapi-engine that executes the asp? ie. if no asp is enabled, then it would serve the asp-pages since iis would consider them as any file (pdf, txt or other) Regards Fredr!k
    Wednesday, October 6, 2004 10:31 AM
  • User-290569074 posted
    BOUND.. take a look at the links on this thread first post. http://asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=709506 The vulerability has to do with bypassing web form authentication on a site not retrieving files from a server.
    Wednesday, October 6, 2004 11:03 AM
  • User-447746187 posted
    Looking at the workaround source code in the KB article, it looks as though using UrlScan (http://www.microsoft.com/technet/security/tools/urlscan.mspx) to canonicalize URLs before they're presented to the runtime should also act as a workaround. The default UrlScan.ini file contains the following section: [DenyUrlSequences] .. ; Don't allow directory traversals ./ ; Don't allow trailing dot on a directory name \ ; Don't allow backslashes in URL : ; Don't allow alternate stream access % ; Don't allow escaping after normalization & ; Don't allow multiple CGI processes to run on a single request which should block the \ explicitly. However, I'm a little wary of using UrlScan on my IIS 6.0 server which runs Exchange Server 2003 Outlook Web Access. For historical reasons, OWA uses the subject line of the email (disambiguated with a hyphen and incrementing number if one already exists) as the final part of the URL - IIRC because it uses Exchange's Installable File System. The net result is that you've no control over the characters which get used in the title. Having said that the message can't have a backslash in the URL because that's not a valid file system character, so applying a limited [DenyUrlSequences] section (containing only the backslash entry) to your OWA server should be OK. I'm also not using Forms Authentication with this server.
    Wednesday, October 6, 2004 3:35 PM
  • User-2031965490 posted
    I've posted this before on the other thread, but let me be clear. URLScan is a great best practice and will help address these types of problems. But in this case, we are highly recommending that you use our global.asax mitigation and follow http://www.microsoft.com/security/incident/aspnet.mspx for new information as it becomes available. -Brian
    Wednesday, October 6, 2004 4:38 PM
  • User600176218 posted
    Win2K3/IIS6 has URLScan already.
    Wednesday, October 6, 2004 4:44 PM
  • User-447746187 posted
    My problem here is that I don't have code ownership: the code for global.asax is all locked away in code-behind, for the services exposed on the Internet from this server (Outlook Web Access, Outlook Mobile Access, SourceGear Vault - we also have a FlexWiki but that one has IP-based access control limiting it to local network only). Is there anything I can do to mitigate this problem without requiring access to the source code?
    Wednesday, October 6, 2004 6:17 PM
  • User-2031965490 posted
    We are working on this -- keep checking the incident page, that is our living document and we are posting stuff to it as it goes live.
    Wednesday, October 6, 2004 9:54 PM
  • User132048738 posted
    uhm, there is no way to avoid hacker using vulnerability SQL system object, SQL Injections with Hexa characters, blinding the Server Logger,... We must work more and try more with our website to security it. I afraid in near future, in somewhere of Flash-Actions Script, still exists vulnerability code. And hacker can attack victim only with the FLASH BANNER!!! Best guard
    Wednesday, October 6, 2004 11:06 PM
  • User-1135537543 posted
    Hey thanks for the replies, http://pluralsight.com/blogs/keith/archive/2004/10/06/2688.aspx is another good article pointed out in a blog this morning. Thanks to Dino Esposito http://weblogs.asp.net/despos/ for that link. Made things more clear for me. And I know I do not have to worry too much about this vulnerability. Since I am not running any of that authentication anywhere. Now not to mean I am not going to put in that code for future and have already put it into all my test servers and test sites. But like MS I have to go through procedures and hoops and change controls to get my code to change on a production site. I mean there are advantages to MS fixing this, one we will trust a patch from MS, we are pretty sure they tested the hell out of it already before it got to us and went through their change process. Easier to get through our change process. But if I all of a sudden I call for emergency change control to change the code in every single one of my asp.net websites, they need rebuilt, retested, approved then redeployed. So thats why it helps to know what all is affected, since I am not using anything that this is vulnerable for, then this code can go in in normal maintenance. Fredrik - Yes this classic asp vulnerability exists on IIS 6 same way it exists in all the others. If you do not install the .net framework. What ever vulnerability your thinking of is not the same vulnerability. I can do a google search on now and come up with a few hundred thousand sites with this vulnerability, it requires yes an admin to do something but it is possible still today. Some other people on this thread touched on the vulnerability, but plain and simple never ever allow directory browsing on your web site and you will be fine. For some reason and never really got into the symantics of why but installing asp.net and then setting up .net on your site eliminates this vulnetability and you can use directory browsing safely. My guess as to why, is different pathing in the asp.dll. Also as far as something not being vulnerable since the mid 90's. Just last month I got a call my boss asked me to go help someone, a novice admin. Thier web server is filling up. Yeah I asked what does filling up mean as well. Anyway, basically when I get there they have a 20 gig drive in it, nothing but windows and a 100 meg website. So where is all the hard drive space going? Well it was Windows NT 4.0 No service packs with IIS 3.0 and full logging turned on. Yes it was that old and no one ever had checked the log files for IIS, they didn't even know they existed. So as far as vulnerabilities that dissapeared years ago, you just think they are gone ;-) There are a ton of inexperienced admins out there working for the smaller companies that as long as it works they are happy.
    Thursday, October 7, 2004 9:48 AM
  • User849839724 posted
    Why is it taking so long to post updates about this issue? This issue was posted on ntbugtraq (http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0409&L=ntbugtraq&F=P&S=&P=9884) 3 weeks ago.
    Thursday, October 7, 2004 10:11 AM
  • User564684961 posted
    I hope a release comes out pretty quickly for this, I know that a lot of folks have code that they can't modify on servers for various reasons.
    Thursday, October 7, 2004 11:01 AM
  • User-1796840278 posted
    You don't necessarily have to modify the code of your application. You can use an HttpModule at the application or machine level to accomplish the same thing. http://blogs.sagestone.net/drobbins/archive/2004/10/06/388.aspx
    Thursday, October 7, 2004 3:46 PM
  • User-1634877164 posted
    Hi Srock, The issue was actually published on NTBugTraq last week. The finder it sent it to the site 2 weeks before that, but the person who ran that web-site didn't publish it until last week (hence the wierdness about the dates). Microsoft was not given an advance warning of this bug -- we were notified along with everyone else last week when NTBugTraq posted it. The microsoft.com website page referenced above is designed to provide real-time updates as we work to fix the issue. Thanks, Scott
    Thursday, October 7, 2004 5:04 PM
  • User-2031965490 posted
    Just a few moments ago we posted new information and guidance related to the reported ASP.NET security vulnerability. This includes several pieces. 1) We updated http://www.microsoft.com/security/incident/aspnet.mspx with new information about the reportedvulnerability. This should help clear up some of the confusion we've seen about what is affected by this. To be super clear, all ASP.NET applications, on ALL OS's should follow the guidance provided. 2) We released a new HTTP Module mitigation best practice. This is in the form of an MSI installer that will help protect all ASP.NET applications on a Web server. This MSI installer will place a binary into the GAC and update the machine.config file for ASP.NET. You can find download information at http://www.microsoft.com/downloads/details.aspx?FamilyID=da77b852-dfa0-4631-aaf9-8bcc6c743026&displaylang=en You can also download the MSI directly at http://download.microsoft.com/download/4/6/1/461433d5-cbac-4721-85cb-c5a514fd0049/VPModule.msi 3) We have posted detailed guidance about the HTTP Module, how the MSI works, and how to deploy it. You can find this KB Article at http://support.microsoft.com/?kbid=887289 We will continue to update the Microsoft.com Security Incident page as new information / guidance becomes available so be sure to check back often. We will also continue to monitor this group if people have questions. Thanks, Brian
    Thursday, October 7, 2004 9:19 PM
  • User500537205 posted
    Hi, Regarding the Global.asax fix for VB.NET: Sub Application_BeginRequest(Sender as Object, E as EventArgs) If (Request.Path.IndexOf(chr(92)) >= 0 OR _ System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then Throw New HttpException(404, "Not Found") End If End Sub Should the test be shortcut with an OrElse if the 92 Char is present: Sub Application_BeginRequest(Sender as Object, E as EventArgs) If (Request.Path.IndexOf(chr(92)) >= 0 OrElse _ System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then Throw New HttpException(404, "Not Found") End If End Sub Thanks, Martin Naughton
    Friday, October 8, 2004 9:36 AM
  • User-2031965490 posted
    Martin, The Global.asax code is written in a very specific way to give you a broad range of canonicalization testing. You should not deviate from the prescribed code sample. Hope this helps. -Brian
    Friday, October 8, 2004 12:30 PM
  • User217144503 posted
    I can not get the bug reported at http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0409&L=ntbugtraq&F=P&S=&P=9884 to show itself on a win2003 w/ IIS 6, but MS has stated that win2003 w/IIS 6 is vulnerable. Has anyone been able to circumvent the forms auth on win2003/IIS 6? Troy
    Friday, October 8, 2004 1:39 PM
  • User-932271937 posted
    I've been installing the vpmodule.msi in our testing environment to prevent this issue and have yet to see that it is adding the 'microsoft.web.validatepathmodule.dll' to the systems and it definitely is not updating the GAC. The package is updating the machine.config, but nothing more. I've been able to duplicate this on WinXP/IIS 5.1/.NET FW v1.1SP1 and Win2003/IIS6/.NET FWv1.1 SP1. It states it installs successfully every time though. If I go do the manual steps outlined in the KB, then the dll is present and the GAC gets updated. Am I missing something or is this MSI package not working correctly?
    Saturday, October 9, 2004 6:43 PM
  • User-447746187 posted
    I dug around in the MSI with dark, from the Windows Installer XML toolset. It doesn't install any files to Program Files, just to the GAC. It does this before running the script which updates machine.config. When testing for the presence of an assembly in the GAC, supply the assembly name, not the file name. gacutil chokes on the .dll extension. On the machines I've run the MSI on: C:\>gacutil /l microsoft.web.validatepathmodule Microsoft (R) .NET Global Assembly Cache Utility. Version 1.0.3705.0 Copyright (C) Microsoft Corporation 1998-2001. All rights reserved. The Global Assembly Cache contains the following assemblies: microsoft.web.validatepathmodule, Version=, Culture=neutral, Publ icKeyToken=eba19824f86fdadd, Custom=null The cache of ngen files contains the following entries: Number of items = 1 There is only one copy in the GAC - the same version is used for .NET 1.0, 1.1 and 2.0 beta 1.
    Sunday, October 10, 2004 6:10 AM
  • User-932271937 posted
    What location is the codebase dll copied to when run with the MSI? When I do the manual steps, I've been putting it in C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322. I've been verifying the module in the GAC by simply using the .NET Configuration tool and viewing all the assemblies. To really confuse me more, I tested on a third platform...Win2k/IIS/.NETFWv1.1SP1. This time when running the MSI, the GAC reflects the module, but I still don't see the dll and the codebase location of the module is blank. So, is the MSI even supposed to copy the dll down to the system or is the dll simply updating the GAC and nothing more? If not, then after the manual implementation, can I delete the dll, even though the codebase location of the module points to that location and dll? I may be beating a horse to death, but I want clearly understand what the MSI is supposed to do and why it is not working consistently in my tests. Thanks to anyone who replies!
    Sunday, October 10, 2004 8:52 AM
  • User-447746187 posted
    The GAC is simply an area of the file system which contains global assemblies. The assembly's files are copied to a directory based on the assembly's version information in the file. The current structure is %SystemRoot%\Assembly\GAC\[assemblyName]\[version]__[publicKeyToken] - on my system running XP SP2, that maps to C:\WINDOWS\assembly\GAC\Microsoft.Web.ValidatePathModule\ for this assembly. The Framework, if deciding to load from the GAC, always loads the files from here. You can observe this with a tool like Process Explorer - look at an aspnet_wp process (Win2k, XP) or a w3wp process (WS03). If installed correctly, you should see the DLL in the DLLs pane. When a file is marked in an MSI as being a .NET assembly, and to be registered in the GAC, the Windows Installer engine doesn't install it anywhere else, even if marked to do so. It simply installs it into the GAC - that's it. Installing an assembly into the GAC with gacutil also makes a copy of the DLL. The codebase doesn't need to be set because the module plugs into an entirely managed stack. Codebase is only necessary for COM Interop, IIRC, when not installed into the GAC.
    Sunday, October 10, 2004 8:28 PM
  • User-932271937 posted
    Thanks Mike! I understand much better about the how, where and why's. My systems don't have a GAC directory under %windir%\assembly, but do list all the assemblies at this location. I guess my only remaining issue is why on 2 out of 3 test systems, the GAC did not get updated with the module using the MSI and I had to manually update it. I'll keep testing as I have a few hundred servers with ASP.NET and don't want to manually update them all. Thanks!
    Monday, October 11, 2004 5:50 AM
  • User-447746187 posted
    I should have added that you'll only see the GAC directory if you use the command prompt. %SystemRoot%\Assembly has a shell extension which causes Explorer to show a different view of the contents. I'd recommend using Windows Installer's logging features. To create a log, instead of double-clicking the MSI to install, use: msiexec /i VPModule.msi /log VPModule.log This creates a log file VPModule.log, in the current directory, for the installation. If you're still having troubles, call the free support line listed at the bottom of the incident page.
    Monday, October 11, 2004 3:00 PM
  • User-660821808 posted
    The download site for VPModule.msi, under System Requirements, indicates Microsoft .NET Framework SDK. I have the .NET Framework 1.0 SP3 installed. Do I need to install the SDK before installing the ValidatePath Module? I would also like to confirm that all I need to do at this time is to install the module?
    Tuesday, October 12, 2004 9:16 AM
  • User-2031965490 posted
    Thanks for pointing this out, I'll review the download center content. What it is intended to say is if you have this software installed on your system, then you should install the mitigation. There is no need to additionally install the SDK for VPModule.msi to work. For now, installing VPModule.msi will help protect you against canoicalzation issues known to Microsoft. Hope this helps. -Brian
    Tuesday, October 12, 2004 4:50 PM
  • User-1319163995 posted
    Is there an official J# version of the Global.asax code? The C# version does not seem to port easily because it throws an HttpException to create the 404 error. The J# signature of BeginRequest does not allow any exceptions to be thrown from the handler, so a naive conversion like: protected void Application_BeginRequest(Object sender, System.EventArgs e) { if (get_Request().get_Path().IndexOf('\\') >= 0 || System.IO.Path.GetFullPath(get_Request().get_PhysicalPath()) != get_Request().get_PhysicalPath()) { throw new HttpException(404, "not found"); } } gets the compiler error: Exception 'System.Web.HttpException' is not caught and does not appear in throws clause. Thanks, Stan
    Wednesday, October 13, 2004 4:37 PM
  • User-2031965490 posted
    Hey Stan -- I'll try to get the J# version added to the KB, but in the mean time -- here is the code ported to J# -- I had the test team verify that it works, so you are all set. protected void Application_BeginRequest(Object sender, System.EventArgs e) throws HttpException { if (get_Request().get_Path().IndexOf('\\') >= 0 || String.Compare(System.IO.Path.GetFullPath(get_Request().get_PhysicalPath()), get_Request().get_PhysicalPath()) != 0) { throw new HttpException(404, "not found"); } } Hope this helps. Thanks, Brian
    Thursday, October 14, 2004 1:45 AM
  • User-1319163995 posted
    Hi Brian, Thanks very much! I checked the code in our local environment as well and it works like a charm. Thanks for the quick response, Stan
    Thursday, October 14, 2004 10:26 AM
  • User-2031965490 posted
    We have been working very hard to make it as easy as possible for customers to respond to the reported ASP.NET security issue. The first steps were to quickly provide guidance for Web site administrators and developers to help protect their apps. Since then, we have been trying to make it even easier to manage deploying the HTTP Module in large multi-server environments. To that end, we updated http://www.microsoft.com/security/incident/aspnet.mspx with additional guidance. In this update we have included several new pieces which will help improve the deployment experience: A new scanning tool that Web site administrators can use to determine if a machine has the HTTP Module installed -- it will also help determine if a box has ASP.NET running so administrators can determine if the module is necessary on a given box. The script makes it easy to automate this process. • Microsoft ASP.NET ValidatePath module scanner (VPModuleScanner.js) Guidance on how to use Group Policy to deploy the HTTP Module in multi server environments. • KB 887405, "How to Use Windows Installer and Group Policy to Deploy the VPModule.msi in an Active Directory Domain" Guidance on how to use SMS to deploy the HTTP Module in multi-server environments • KB 887404, "How to Use Systems Management Server 2003 to Deploy the ValidatePath Module" Updated the HTTP Module guidance to include source code for the HTTP Module. • KB 887289, "HTTP Module to Check for Canonicalization Issues with ASP.NET." Please continue to look to the security incident page for more information as it becomes available and let me know if you have any questions.
    Friday, October 15, 2004 6:54 PM
  • User-1167560136 posted
    ===================================== Hi, Regarding the Global.asax fix for VB.NET: Sub Application_BeginRequest(Sender as Object, E as EventArgs) If (Request.Path.IndexOf(chr(92)) >= 0 OR _ System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then Throw New HttpException(404, "Not Found") End If End Sub Should the test be shortcut with an OrElse if the 92 Char is present: Sub Application_BeginRequest(Sender as Object, E as EventArgs) If (Request.Path.IndexOf(chr(92)) >= 0 OrElse _ System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then Throw New HttpException(404, "Not Found") End If End Sub Thanks, Martin Naughton ===================================== Martin, The Global.asax code is written in a very specific way to give you a broad range of canonicalization testing. You should not deviate from the prescribed code sample. Hope this helps. -Brian ===================================== Hi Martin, Despite Brian's statement that your should not deviate, you should change the Or to an OrElse. After all that is exactly what the C# version is using (|| short circuits). If the GetFullPath version of the OR should always be executed, it should be first part tested, then the C# version is wrong. Cheers... Robert Slaney
    Sunday, October 24, 2004 5:49 PM
  • User2126577562 posted
    Microsoft ASP.NET ValidatePath Module http://www.microsoft.com/downloads/details.aspx?familyid=DA77B852-DFA0-4631-AAF9-8BCC6C743026&displaylang=en
    Tuesday, October 26, 2004 3:54 PM
  • User62888220 posted
    Thank you very much! I get it !
    Tuesday, November 30, 2004 8:48 PM
  • User-925501833 posted
    Good Morning, We have applied the patch specified in KB 887289, VPModule.MSI to our Windows 2000 Server. On a regular basis we utilize a third party vulnerability scanner from Qualys. The scan on port 80 doesn't detect the patch as missing, it see's it installed. When I scan the server on port 443 it detects the server as unpached. I have verified the update is in place. Does this HTTP update not cover HTTPS? If not what should we do to protect our system? Thanks, Todd Day
    Monday, January 10, 2005 9:53 AM