Home page logo
/

bugtraq logo Bugtraq mailing list archives

Considerations for IIS Authentication (#NISR05032002C)
From: "David Litchfield" <nisr () nextgenss com>
Date: Tue, 5 Mar 2002 18:00:06 -0000

NGSSoftware Insight Security Research Advisory

 

Name:                     Considerations for IIS Authentication
Systems Affected:         Microsoft IIS 4/5/5.1
Platforms:                Windows NT/2000/XP
Severity:                 Low/Medium Risk
Vendor URL:               http://www.microsoft.com/
Author:                   David Litchfield (david () nextgenss com)
Date:                     5th March 2002
Advisory number:          #NISR04032002C
Advisory URL:           http://www.nextgenss.com/advisories/iisauth.txt

Issue:                    Information leakage and brute force attacks on
                                user accounts is possible.

 

Description
***********
Microsoft's Internet Information Server offers web, ftp, mail and nntp
services. It is possible to force the web service to authenticate a user
even if anonymous access is allowed to the resource being requested.
This may open three low risk vulnerabilities on the server - two
problems with information leakage and the possibility to perform brute
force attacks against system user accounts.

 

Details
*******
IIS supports anonymous access, Basic authentication and Integrated
Windows authentication using NTLM. By making a request to the web server
offering credentials the web server will attempt to authenticate the
user. If authentication fails the server responds with a 401 Access
Denied message. Depending upon what forms of authentication have been
disabled or left enabled different actions can be performed.

To ascertain if the server supports Basic Authentication one would make
a request with the following Authorization header:

 
GET / HTTP/1.1
Host: iis-server
Authorization: Basic cTFraTk6ZDA5a2xt

 
If the server responds with a 401 Access Denied response then Basic auth
is enabled. If the server responds with a 200 OK then this means one of
two things - the server does not support Basic auth (the most likely) or
there is a system account on the server called "q1ki9" with a password
of "d09klm" (most unlikely!).

To ascertain if the server supports NTLM Authentication one would make a
request with the following Authorization header:

 
GET / HTTP/1.1
Host: iis-server
Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA=

 
Again if the server responds with a 401 Access Denied message then the
server supports NTLM auth. If a 200 OK response is returned then the
server does not support Integrated Windows authentication.

Provided at least one authentication method is supported an attacker can
mount a brute force attack against system accounts. More than likely the
default "administrator" account would be the target as normally this
account can't be locked out and is highly privileged.

In terms of information leakage, if Basic auth is supported when making
a request whatever is entered in the client Host HTTP header is used as
the Realm. The Realm information is served by the server to the client
so the client can tell when it should or shouldn't present
authentication credentials. If the Host header field is left blank the
server will, by default, use its IP address as the Realm. If the server
is protected by a firewall that employs Network Address Translation and
has a private IP address such as 10.x.x.x then this will be returned to
the client. This information can aid an attacker when formulating other
attacks.

If NTLM authentication is supported then it is possible to discover the
NetBIOS name of the server and the Windows NT domain it resides in. This
information is returned as Base64 encoded text in response to a client
Authorization request.

 

Fix Information
***************
If the server is intended for public use then it may be possible to
simply disable both Basic and Integrated Windows authentication. Sites
that use forms based logins, for example when users are authenticated
against a database, and track logged in users with cookies will be able
to disable these authentication methods. Doing this will prevent such
attacks.

If Basic or Integrated Windows authentication are required then it is
possible to mitigate the risk.

Setting account lockout will help minimize the risk of successful brute
force attacks. Using the "passprop" utility it is possible to enable
account lockout for the default "administrator" account.

One should also seriously consider renaming this administrator account
if this has not already been done.

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 but didn't consider it to be a problem.





  By Date           By Thread  

Current thread:
  • Considerations for IIS Authentication (#NISR05032002C) David Litchfield (Mar 05)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault