Windows NT NTML Auto-Authentication

Summary
Description:Internet Explorer running on NT will attemt to authenticate using your (hashed) password to anyone who asks! Worse, it doesn't even tell you that it is doing this. Even if you have a very strong password, a man-in-the-middle attack is possible. The server can request a challenge from another server, and then feed it back to you for encryption!
Author:Paul Ashton <paul@argo.demon.co.uk>
Compromise:WWW servers can obtain authentication information (username and Lanman password hash) from clients who connect using Internet Explorer from an NT box.
Vulnerable Systems:NT 4.0, probably 3.51
Date:April 1997 or so
Notes:See Paul Ashton's demonstration at http://www.efsl.com/security/ntie/ . Also not that this isn't fixed as of 7/27/97. Will it ever be?
Details

[Note:  This is from   http://www.efsl.com/security/ntie/  -Fyodor]

MS Internet Explorer authentication

The situation

Without your knowledge, MS Internet explorer on Windows NT transparently
attempts to authenticate with a remote Web server that requests NTLM
authentication. 

During the authentication negotiation, IE sends your username, domain name
or workgroup and hostname in the clear to anyone who asks. This is a
serious flaw in itself. 

The remote server than chooses and sends an 8 byte challenge to the
client. Your IE client on NT will then encrypt a function of your password
with this challenge, and send it back to the server. The server should
compare its version of your encrypted password with the one sent by the
client to complete the authentication. 

In fact two versions of your encryped password are sent, one of which is
based on the full length and character set of your password up to 128
characters, the other one is the first 14 characters of your password in
upper case. 

The problems

     The server is free to send the same challenge to every client that connects to it. 
     The server is free to request a challenge from another server and send that for you to be encrypted. 
     The client cannot detect whether this authentication process has occurred. 
     The client cannot verify whether it is talking to an authentic server. 
     The client cannot prevent the server using the clients authentication token to attach to any file server/web
     server/MS Exchange server/etc. that it wishes to. 

The repercussions

By setting the challenge to a constant the server can pre-compute a
massive database of possible passwords and instantly detect whether the
client is using any one of these. 

Even if the user uses a strong password, the server can spend as much time
as it wishes in the future to attempt to guess the password without ever
having to contact a real NT server. 

The solutions

     Immediately upgrade to Netscape 

     Disable the NTLM SSP service in control-panel/services (though this
may be detrimental to other services on NT)

     Upgrade to Unix, you know it makes sense

The test

This only works with Internet explorer on windows NT

After you have tried this, please change your password immediately,
whether it was guessed or not. Note that the dictionary in use is quite
small.

                                           Try it

Credits

Thanks to Craig H. Rowland for the suggestion of attacking the MS
Exchange/WWW authentication protocol with the static challenge problem
observed for file sharing. 

Thanks to Evolution for hosting this demonstration. 

Contact the author Paul Ashton of Eigen Solutions Ltd. 


More Exploits!

The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's Linux Solaris/SunOS Micro$oft
*BSD Macintosh AIX IRIX
ULTRIX/Digital UNIX HP/UX SCO Remote exploits

This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: