[24576] in bugtraq
Re: IIS Internal IP Address Disclosure (#NISR05032002B)
daemon@ATHENA.MIT.EDU (Eric)
Wed Mar 6 19:08:31 2002
Message-Id: <5.1.0.14.0.20020305195124.023001a0@mail.tellurian.net>
Date: Tue, 05 Mar 2002 20:03:08 -0800
To: "David Litchfield" <nisr@nextgenss.com>, <bugtraq@securityfocus.com>,
<NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
From: Eric <ews@tellurian.net>
In-Reply-To: <01b701c1c46f$6adf7d50$1b01010a@computername>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Please note that the "workaround" has been documented in KB article Q218180
(http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q218180&ID=KB;EN-US;Q218180)
and has been discussed and referenced in the IIS4 and IIS5 security
checklists (since June 2000.)
From the IIS5 checklist
(http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/iis5chk.asp)
Disable IP Address in Content-Location
The Content-Location header can expose internal IP addresses that are
usually hidden or masked behind a Network Address Translation (NAT)
firewall or proxy server. Refer to Knowledge Base article Q218180 for
further information about disabling this option.
At 05:58 PM 3/5/2002 +0000, David Litchfield wrote:
>NGSSoftware Insight Security Research Advisory
>
>Name: Internal IP Addresses and IIS
>Systems Affected: Microsoft IIS 4/5/5.1
>Platforms: Windows NT/2000/XP
>Severity: Low Risk
>Vendor URL: http://www.microsoft.com/
>Author: David Litchfield (david@nextgenss.com)
>Date: 4th March 2002
>Advisory number: #NISR05032002B
>Advisory URL: http://www.nextgenss.com/advisories/iisip.txt
>
>Issue: Possible to discover internal IP addresses used
> by IIS Servers
>
>Description
>***********
>Microsoft's Internet Information Server offers web, ftp, mail and nntp
>services. If the server is protected by a firewall using Network Address
>Translation and the server uses a private internal IP address then, by
>making a malformed request to the web service it is possible for an
>attacker to discover this IP address. Whilst this won't come anywhere
>near to allowing an attacker to compromise a IIS server it will help
>them formulate further attacks. This issue is similar to the issue
>documented at
>http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q218180&id=KB;EN
>-US;Q218180
>
>
>Details
>*******
>By making certain requests to the web service with a blank Host HTTP
>client header the server response will often contain the server's IP
>address, for example when using the PROPFIND request method.
>
>PROPFIND / HTTP/1.1
>Host:
>Content-Length: 0
>
>The server will return a 207 Multi-Status response with certain
>properties of the root page. The server's IP address will be revealed if
>the HREF property. Using the WRITE or MKCOL method will return the
>machine's IP address in the Location server HTTP header, though of
>course if the server allows the WRITE and MKCOL methods then the server
>has greater problems.
>
>Only IIS 5 and 5.1 support the WebDAV methods so these methods only
>affect these systems. IIS 5.x and 4.0 are both vulnerable to this issue
>if Basic authentication is enabled. (see #NISR05032002A
>http://www.nextgenss.com/advisories/iisauth.txt)
>
>
>
>
>Fix Information
>***************
>To prevent internal IP address disclosure take the following steps.
>
>Open a command prompt and change the current directory to
>c:\inetpub\adminscripts or to where the adminscripts can be found.
>
>Run the commands
>
>adsutil set w3svc/UseHostName True
>net stop iisadmin /y
>net start w3svc
>
>This will cause the IIS server to use the machine's host name rather
>than its IP address.
>
>
>Vendor Status
>*************
>Microsoft was informed of this issue. They didn't need to take any
>action as a suitable work-around is available.
