Crackers against Smut

Fravia's Server exploits: ONE
(elementary Micro$oft's insecurity: IIS)

~
(How to fish scripts or programs that should have been hidden)

~
By Fravia+, Started 06 September 1998
Page severely under construction... SEND MORE CONTRIBUTIONS!

Thank to Mark & Paul for part of the following

Micro$oft IIS fishing possibilities

If you want to hide code or programs, most will advice you that, given the choice of server side or client side scripting, you should always choose server side, because it hydes your code from prying eyes. Well, this is not always so.

Microsoft IIS has a nice bug: if you enter the name of a script-based page into your browser and put a full stop at the end of the URL, IIS returns the raw ASP page, rather than the script output.

This exploit was published some months ago and Microsoft provided a fix for it (which as you know does not mean anything at all, since the rate of internet bug-fixing is well below 45% :-) and now another new exploit has been found: under certain circumstances you can get hold of any ASP script, or even grab copies of executables sitting on your target server.

The exploit is based on the fact that the native Windows NT file system (NTFS) supports multiple data streams within a single file. Here the MS 'online' documentation:


Multiple Data Streams



NTFS supports multiple data streams. The stream name identifies 

a new data attribute on the file. Streams have separate opportunistic 

locks, file locks, allocation sizes, and file sizes, but sharing is per file. 



The following is an example of an alternate stream:



myfile.dat:stream2





This feature permits related data to be managed as a single unit. 

For example, Macintosh computers use this type of structure to 

manage resource and data forks. Or, a company might create a program 

to keep a list of changes to the file in an alternate stream, thus 

keeping archive information with the current version of the file.



As another example, a library of files might exist where the files 

are defined as alternate streams, as in the following example:



library:file1

       :file2

       :file3



Suppose a "smart" compiler creates a file structure like the following example:



program:source_file

       :doc_file

       :object_file

       :executable_file



Note Because NTFS is not supported on floppy disks, when you copy an NTFS 

file to a floppy disk, data streams and other attributes not supported by 

FAT are lost.

The really important data stream is called $Data, the stream that stores the actual content of the file. If you type in the UTL of a script you are interested in, and you add ::$DATA to the end of it, for example

http://www.target.com/security.asp::$DATA
the server mappings will be bypassed and the raw script returned. Just what 'secure' e-commerce enabled sites need :-)

Obviously this can only happen if the files are being stored on an NTFS volume, so anyone running web server off a FAT volume will not be affected by this exploit, but there are so many exploit out there for FAT volumes, that to get those scripts is as easy as shooting the red cross.

Note that this regards ASP, PL, IDC, SHTML and any other script or executable file types!

Never forget that root is usually

\inetpub\wwwroot in M$ Internet Information Server,
\home\httpd in Apache
and that lazy sysads (or all sysads that have had enough with all bugs) tend to stuff most of the things inside root.

Another interesting example (for instance perusing bank accounts), is that if you find somewhere a 'forgotten' Access database file in some remore subdirectory of your target you just need to point your browser to this file (if you have Access installed on your system) in order to see the whole database. It's read-only, of course, but hey: info is info!

Good luck, good hunt!

Crackers against Smut