aspads.txt

`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  
[email protected] & [email protected])  
  
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 <[email protected]>)  
  
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:[email protected]]  
Sent: Tuesday, June 30, 1998 9:28 AM  
To: [email protected]  
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  
`