Trivial forwarding attack on NTLMv2 authentication
Friday, August 13th, 2010NTLM (v1 and v2) and MS-CHAP (v1 and v2) are challenge-response authentication protocols which are designed to be compatible with the hashing algorithms windows uses to handle password credentials. The challenge-response system solves the obvious problem of previous protocols which tended to simply transmit the password in the clear. However, NTLM is still susceptible to credentials forwarding attacks, it simply has little or no built-in defenses against them. What this means is that an active attacker (i.e., one who can modify traffic on the network between the client and server) is able to redirect a few bytes in one direction, a few bytes in the other, and “steal” the login from the legitimate client and use it to authenticate his own connection to the server. Effectively, this challenge-response scheme amounts to a one-time password transmitted in the clear.
I was honored to be a guest presenter at Dan Geer’s talk today at the Usenix Security Symposium 10. We talked about the need to fix network protocols and the unique challenges that presents. Although I had originally planned to talk about the SSL/TLS experience, I took this opportunity to present what I had learned about NTLM after spending some time looking into the issue over the past few weeks.
People in-the-know have been aware of this attack for at least 14 years. The security research community discussed it repeatedly years back, but somehow it fell through the cracks and was forgotten. But today’s hostile networking environment has given us a newfound appreciation of the need to keep up with any detail which might have implications for data security, so possibly this is the right time to raise awareness of this problem once again. Spread the word.
I’ll be updating this post with more technical detail, so watch for changes over the next day. Until then, I’ll post some links to material as it’s available.
Attack demo videos by Liam Schneider
SMB relaying with a fully-patched Windows
Other
Slides from Usenix Security 2010 presentation
Press
Authentication under Windows: A smouldering security problem - The H
Papers, Presentations, and Published Attacks
1996 - Dominique Brezinski - A Weakness in CIFS Authentication
1997 - Brezinski - BlackHat - Security posture assessment of Windows NT networks
1999 - Schneier, Mudge, Wagner review PPTP+MSCHAPv2
2000 - DilDog - @stake - Telnet NTLM Replay Vulnerability
2001 - Sir Dystic - Cult of the Dead Cow - @lantacon - SMBRelay
2004 - Jesse Burns - iSEC -NTLM Authentication Unsafe, HTTP to SMB attack demo
2007 - Grutzmacher - Squirtle
2007 - HTTP to SMB implemented in Metasploit
2007 - HD Moore, valsmith - BlackHat - Tactical Exploitation
2008 - Eric Rachner exploits HTTP-HTTP
2008 - Andres and Miguel Tarasco Acuña - SMBrelay3
Recognized vulnerabilities arising from this fundamental weakness in NTLM
CVE-1999-1087 MS98-016 IE interprets a 32-bit number as an Intranet zone IP address
CVE-2000-0834 MS00-067 Patch for “Windows 2000 Telnet Client NTLM Authentication” CVE-2001-0003 MS01-001 Patch for MS Office “Web Extender Client” to use IE settings CVE-2005-0147 Firefox responds to proxy auth requests from arbitrary servers
CVE-2008-3009 MS08-076 Windows Media do not use the SPN for validating replies
CVE-2008-3010 MS08-076 Windows Media associates ISATAP addresses with Intranet zone
CVE-2008-4037 MS08-068 SMB credential reflection protection
CVE-2009-0550 MS09-013 WinHTTP doesn’t correctly opt-in to the NTLM reflection protection
CVE-2009-0550 MS09-014 WinINet doesn’t correctly opt-in to the NTLM reflection protection
CVE-2009-1930 MS09-042 Telnet protocol doesn’t correctly opt-in to the NTLM reflection protection
CVE-2009-3983 Firefox allows remote attackers to replay NTLM credentials of the user
CVE-2010-0231 Hernan Ochoa, Augustin Azubel - BlackHat - Windows’ SMB PRNG is pwned (somewhat unrelated, but too good not to mention)
CVE-2010-1413 Webkit sends NTLM in unspecified circumstances.
Notes
Most or all of the current patched mitigations appear to be less than completely effective. For example read about the remote code execution vulnerability MS08-068. Except that when you see the words “reflection protection” mentally substitute “protection that can be bypassed by simply targeting a different machine”.
Starting with Vista, a MIC (message integrity code) has been included in the messages. However, it probably can’t be very effective unless clients and servers are willing to refuse to make connections with remote endpoints that do not supply it. It signs the content of the messages in each direction, but it doesn’t look like any new info has been “bound” into the authentication process. For example, the target server may be checked, but an attacker may still be able to forward the credentials to a different port and protocol on the same server. In some scenarios (e.g., http rewriting) the bad guy may be the one specifying the target server in the first place.