Alert: ASP vulnerability with Alternate Data Streams

[aleph1 () DFW NET (Aleph One)]

---------- Forwarded message ----------
Date: Thu, 2 Jul 1998 10:14:58 -0400
From: Russ <Russ.Cooper () RC ON CA>
To: NTBUGTRAQ () LISTSERV NTBUGTRAQ COM
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
jasonw () THECRIB COM & dave () DATACASH COM)

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 <helpmaster () EXCHANGE ODC EDU>)

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:paul () ARGO DEMON CO UK]
Sent: Tuesday, June 30, 1998 9:28 AM
To: NTBUGTRAQ () LISTSERV NTBUGTRAQ COM
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