exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ms-iis4-siteserver2.txt

ms-iis4-siteserver2.txt
Posted Aug 17, 1999

ms-iis4-siteserver2.txt

tags | exploit
SHA-256 | dd0c2ecfd9f1bff3d0d78d38334293cb6fe3cc8fe2fec927b0d3c2517702dc71

ms-iis4-siteserver2.txt

Change Mirror Download
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/

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close