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/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:02 PDT