---------- Forwarded message ---------- Date: Thu, 2 Jul 1998 10:14:58 -0400 From: Russ <Russ.Cooperat_private> To: NTBUGTRAQat_private Subject: Alert: ASP vulnerability with Alternate Data Streams We've had a number of questions and possible solutions suggested in the past few hours, let me try and summarize. 1. Several people noted that enabling extensions with "::$DATA" added, i.e. ".asp::$DATA", would cause them to be executed instead of read. This does work, and is faster than removing READ access from all of the files you are concerned about. I would still recommend removing READ access as a matter of course. (credit Somer Bozyel) 2. Someone asked whether or not anything other than $DATA would work. The only "pre-defined" stream available on any file is the ::$INFORMATION_SECURITY stream. This does not seem to yield any results when appended to a URL. Other streams might work, but then they would have to be defined by the person owning the server, and only they would know the stream names (unless you could remotely execute March's stream display program). 3. Secondly, a number of people are reporting sites that seem to be unaffected. There may be a couple of reasons a site appears to be unaffected (I haven't received a link yet that I couldn't exploit, aside from http://www.ntbugtraq.com which I fixed up late last night). Depending on where the ASP code is in the page, a site may appear to display normally (or almost normally). That's because the HTML is being interpreted and display while the asp is being quelched due to its enclosing tags. If you do a "View Source" on such a page, you may very well see the entire ASP. If a site really is unaffected then its due to the READ permissions not being enabled (or they've added the extension with "::$DATA" to their scriptmappings). 4. Put all executables into a separate directory and make that directory READ disabled. This may make it easier to know what's at risk, but it may not be easy to change the location of some files. (credit jasonwat_private & daveat_private) 5. Cold Fusion .CFM files are visible also, but when READ disabled they do execute properly, so make sure you consider all forms of executables and not just ASPs (credit Arron <helpmasterat_private>) Note: I've left Paul's original message attached because it didn't go out with an "Alert:" at the beginning of the subject line, meaning some list members did not see it. Cheers, Russ - NTBugtraq moderator -----Original Message----- From: Paul Ashton [mailto:paulat_private] Sent: Tuesday, June 30, 1998 9:28 AM To: NTBUGTRAQat_private Subject: ASP vulnerability with Alternate Data Streams Following on from the last .asp vulnerability which applied to URLs ending in spaces, and the previous that allowed .asps to be read if they end in ".", it turns out that there is yet another due to Alternate data streams. The unnamed data stream is normally accessed using the filename itself, with further named streams accessed as filename:stream. However, the unnamed data stream can also be accessed using filename::$DATA. If you open http://somewhere/something.asp::$DATA it turns out that you will be presented with the source of the ASP instead of the output. Deja vu?! It is left as an exercise for the reader to thing of further implications in other programs running on NT. Obviously, anything that to tries to restrict access based on filename instead of ACLs is going to have a hard time after this and the other recent revelations. Paul
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:01:46 PDT