Windows NT NTML Auto-Authentication
|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 <firstname.lastname@example.org>|
|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? |
[Note: This is from http://www.efsl.com/security/ntie/ -Fyodor]
MS Internet Explorer authentication
Without your knowledge, MS Internet explorer on Windows NT transparently
attempts to authenticate with a remote Web server that requests NTLM
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
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.
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.
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
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
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.
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
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 resouces:
[ Nmap |
Sec Tools |
Mailing Lists |
Site News |