(NTLMv2 Corrects the Flaw) Re: Microsoft NTLM Authentication Protocol Flaw Lets Malicious SMB Servers Gain Access to Systems
SecurityTracker Alert ID: 1006625|
SecurityTracker URL: http://securitytracker.com/id/1006625
(Links to External Site)
Date: Apr 22 2003
User access via network|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): All versions of Windows|
A vulnerability was reported in the Microsoft NTLM Authentication implementation used by the Windows Server Message Block (SMB) protocol and other services in all Windows operating systems. A remote user acting as a malicious SMB server can gain access to a target user's shared resources.|
It is reported that a remote user, acting as an SMB server, can gain access to user-level file and printer sharing services in certain cases. The remote user must entice the target user to connect to the malicious SMB server to exploit the flaw. This can reportedly be achieved in an automatic fashion by sending an HTML page that contains content hosted on the malicious SMB server to the target user (there may be other methods to get the target host to request an SMB connection).
If the target user is already logged in, the target user's host will send a request to the malicious SMB server to attempt to authenticate to that malicious SMB server. Instead of responding with a challenge, the malicious SMB server turns and acts as an SMB client and sends a request to the SMB services on the target user's host. The SMB server on the target user's host will, of course, respond with a challenge, which the malicious SMB client then sends to the malicious SMB server on behalf of the original target host. The malicious SMB server then sends the challenge back to the original target host.
At this point, the target host will perform the proper NTLM authentication steps, encrypting the password with the received challenge, sending the results back to the malicious SMB server. The malicious SMB server returns the results to the malicious SMB client, which then sends the received results to the target SMB server. The target SMB server will then successfully authenticate the malicious SMB client, giving the remote user authenticated access to the target user's shared files and printer resources.
The authors of the report indicate that they have developed exploit code but have not released the code.
A remote user with the ability to act as a malicious SMB server can gain access to a target user's SMB shared resources with the privileges of the target user.|
Microsoft reports that NTLMv2 (released in 1998 for NT 4.0) can be used to protect against this flaw, as described in the Windows 2000 Security Hardening Guide, available at:|
The downloadable version with templates is available at:
The vendor also reports that Kerberos, which is the default negotiation in Windows 2000 and more recent systems, will prevent this type of exploit.
Vendor URL: www.microsoft.com/technet/security/ (Links to External Site)
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Subject: RE: Authentication flaw in microsoft SMB protocol|
> -----Original Message-----
> From: Dave Aitel [mailto:email@example.com]
> Also found and demonstrated by dildog at defcon 3 years ago. So don't
> hold your breath waiting for that patch.
You don't need to wait. This is prevented with NTLM v.2, which shipped
with Windows NT 4.0 SP4 in October 1998. This type of attack is also
foiled with Kerberos, which is negotiated by default in a Windows 2000
or higher domain.
To learn more about using NTLM v.2 and Kerberos, refer to the Windows
2000 Security Hardening Guide:
> > When
> > a logged-in user requests for a network share on the
> server, Windows
> > automatically sends the encrypted hashed password of the logged-in
> > username to the target SMB server before prompting for password.
This is not correct. Window sends a response to a server challenge. The
response is computed from the users hash and the challenge sent by the
server. Passwords, hashed, encrypted or otherwise, are never sent on the
wire during a connection.
Jesper M. Johansson
Security Program Manager