Considerations for IIS Authentication (#NISR05032002C)

From: David Litchfield (nisrat_private)
Date: Tue Mar 05 2002 - 10:00:06 PST

  • Next message: obscure: "Re: RealPlayer bug"

    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 (davidat_private)
    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.
    



    This archive was generated by hypermail 2b30 : Tue Mar 05 2002 - 13:44:33 PST