Date: Thu, 11 Feb 1999 17:37:18 -0500 From: Gary Geisbert To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Using FSO in ASP to view just about anything This active server page opens the FileSystemObject and streams the contents of the file specified in the "file" parameter. The problem with FSO is that you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../". e.g. http://www.server.foo/showfile.asp?file=../../global.asa Another problem is that since the file is being read with a TextStream, ASP code will not be executed. So if the file specified is an ASP file, the results will be similar to the ::$DATA exploit. For example: If this file was placed on the server of a web hosting company who allows ASP, a malicious user could use it not only to view the source of *any* other user's ASP code, but also (with a small modification) stream data into other users' ASP files. This would essentially overwrite whatever is currently there. -------[ cut here: showfile.asp ]------- <% ' grab the file from the URL FileName = Request.QueryString("file") ' create the filesystemobject and open the file Set fso = CreateObject("Scripting.FileSystemObject") Set ts = fso.OpenTextFile(Server.MapPath(FileName)) ' read the contents ShowTheFreakinThing = ts.ReadAll ' display them Response.Write ShowTheFreakinThing ' EOF %> -------[ cut here: showfile.asp ]------- That's about it. Email me if you have questions. -Gary Geisbert (gary@newsletters.com) -------------------------------------------------------------------- Date: Thu, 11 Feb 1999 16:25:46 -0700 From: Joel Maslak To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Using FSO in ASP to view just about anything At 05:37 p.m. 11/02/99 -0500, you wrote: >This active server page opens the FileSystemObject and streams the contents >of the file specified in the "file" parameter. The problem with FSO is that >you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../". Yes, this is a fairly well known bug. Solution? NTFS permissions. Simply run each virtual web as a different user, and make sure that user can't view each other's virtual webs, but only it's own virtual web. This feature is actually quite useful when you need to "break out of the mold" of traditional design. One thing that should be noted is ANY ActiveX server can be executed by a user, by simply doing a server.CreateObject in the ASP file. Obviously, the security ramifications of this can be quite severe. You can open up MS Outlook, and using the mail object, send mail. Neat feature for some people, but scarry if you look at some the other interfaces in some of your applications (think attachments!)... Do your users really have a legitimate purpose in starting up, say, Word (never tried this, but I bet it would work). This is a much bigger issue. An example of this use is at: http://www.swynk.com/friends/datema/excelface.asp It would be nice to have a way of limiting what objects can be created by server.CreateObject (yes, I realize this is probably a big modification). In addition to this feature, how about... You might be able to get access to any file stored on the server w/o sufficient permissions (think credit card orders). Joel Maslak UPDATE -- Generate Web Traffic http://www.permission-marketing.com/ -------------------------------------------------------------------- Date: Fri, 12 Feb 1999 10:51:07 -0500 From: Russ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Using FSO in ASP to view just about anything Folks, I would appreciate it if people would send their responses to Gary (gary@newsletters.com) and I would ask Gary to summarize to the list. I let Gary's message out not because it was a bug (and to that extent, I should have asked Joel to change his message), but because it does represent a reasonable vulnerability that could be easily overlooked. In the meantime; Phillip R. Paradis said... This exploit does not work in IIS4 if you deactivate the Allow Parent Paths option in Internet Services Manager. Under the application root properties, select configuration, app options, and deselect Allow Parent Paths. This prevents MapPath from resolving anything with a .. in it. Martin DEVERA said... >It would be nice to have a way of limiting what objects can be created by >server.CreateObject (yes, I realize this is probably a big modification). there is a way, you can set perms to a registry value HKCR\Classes\{YourID} and so disallow particular user groups to read it. It effectively disables user to create an object. Cheers, Russ - NTBugtraq moderator