ms-iis4-siteserver2.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType
packetstorm🔗 packetstormsecurity.com👁 23 Views
Unauthorized file uploads in Internet Information Server can lead to system compromise risks.
`Date: Sat, 30 Jan 1999 13:02:09 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
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/  
  
`
17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4