ms-iis4-siteserver2.txt
dd0c2ecfd9f1bff3d0d78d38334293cb6fe3cc8fe2fec927b0d3c2517702dc71
Date: Sat, 30 Jan 1999 13:02:09 -0000
From: mnemonix <mnemonix@GLOBALNET.CO.UK>
To: BUGTRAQ@netspace.org
Subject: Security Advisory for Internet Information Server 4 with Site Server 2.
[ The following text is in the "iso-8859-1" character set. ]
[ Your display is set for the "US-ASCII" character set. ]
[ Some characters may be displayed incorrectly. ]
Whilst doing a pentration test recently I came across a quite interesting
hole that IIS administrators
should be aware of.
If MS Site Server 2.0 is installed with IIS4 it can allow unauthorized users
to upload content, including Active Server Pages, to the web site.
Normally a directory called "users" is created on the web root by an
Administrator and authorised users can then go to
http://www.example.org/scripts/uploadn.asp
be prompted for a User-ID and password and on successful authentication
upload files to the server. This is very useful in an Intranet situation to
allow employess to place HTML based documents about themselves and their
department on the corporate Intranet Server.
Importantly, even if the "users" directory does not already exist it will be
created automatically on the first successful upload. On creation, by
default, the NTFS file system permissions allow the EVERYBODY group Change
access. This allows for , amongst other things, creation, changing and
deleting of files in that directory or any sub-directory.
As far as Internet Information Server is concerned, the directory is given
scripting permission, that is resources such as Active Server Pages will be
executed, and more importantly the "Write" access is given allowing any
anonymous user, under the guise of the Anonymous Internet Account
(IUSR_MACHINE), to create files, via HTTP using the PUT request method.
These factors leave the server wide open to a system compromise. During the
pen-test when in which I came across this the sever could only be accessed
via HTTP from the Internet side of their firewall. They had enabled the
Guest account on this machine, believing that there was no danger in doing
so (as far as they were concerned NetBIOS based traffic was blocked by the
firewall as was ftp etc) giving corporate users Guest access to the web
server if so needed. They had given the Guest account a password of
"guest". Using this account I was able to create the /users directory and
upload some ASP pages and the server was compromised. A little later the
whole of the network was compromised using the web server as my attack
platform.
Even if the Guest account had not been left wide open - had some user of the
LAN tried uploading something, let's say out of interest, the /users
directory would have been created with the defaults - meaning the server is
still compromisable. Although without a password you can't use the services
provided for by Site Server you could simply telnet to port 80 on the Web
Server and issue something like:
PUT /users/non-aggressive-script.asp HTTP/1.0
Content-length: 120
Entity-body:
<HTML>
<BODY>
Request method is <% Response.Write
Request.ServerVariables("REQUEST_METHOD") %>.<BR>
</BODY>
</HTML>
\n
\n
\n
and a 201 Created response will be elicited. Once the file has been created
it is then requested from a browser. The ASP code executes and the page is
returned - "Request method is GET" .
I have incorporated checks for this issue into NTInfoScan. More information
about NTInfoScan can be found at
http://www.infowar.co.uk/mnemonix/ntinfoscan.htm
Those that might be vulnerable to this problem should take the following
steps.
If you don't need Site Server remove it and delete the following files from
the /scripts directory
cpshost.dll
uploadn.asp
uploadx.asp
upload.asp
repost.asp
postinfo.asp
Use the IIS MMC and check that no directory accessible from the Web has been
given the "write" permission.
If you want to keep Site Server, and even if you don't, ensure that the
Anonymous Internet Account has absolutely no write access to your file
system - use NTFS file permissions to lock down the server.
Cheers,
David Litchfield
http://www.infowar.co.uk/mnemonix/