Security flaws haunt NTLMv1-2 challenge-response protocol

Guest editorial by Marsh Ray

Today at the Usenix Security Symposium, I'll be an unannounced guest speaker in Dan Geer's talk on "Vulnerable Compliance". I'll be talking about the challenges raised in fixing security bugs when they are found in network protocols. There will be two case studies. One is, of course, the SSL/TLS Authentication Gap, which happily over the last nine months has been patched by most vendors (including Microsoft).

The other will discuss a potentially more serious issue with another commonly used protocol: NTLM (aka NTLMv2, MS-CHAPv2). NTLMv2 is the challenge-response protocol for performing MS Windows password authentication over the networks. It's used any time a password needs to be provided to a Windows or Samba server and the client is not part of the Windows Active Directory domain. Often this happens implicitly (it can even be triggered by the attacker). When NTLM was developed, the challenge-response mechanism was a vast improvement over sending the password in the clear where it could be readily observed. Bugs in NTLMv1 allowed password-grabbing attacks which were fixed in NTLMv2. Password compromises are high visibility attacks which garnered plenty of attention, but that mainly served to distract from the more fundamental issue I'm describing.

The deeper problem is that NTLMv1-2 provide absolutely no protection against credentials forwarding/relay or reflection attacks. This means that an active attacker (such as a man-the-middle) is sometimes able to redirect the login of the legitimate user to authenticate his own session.

This design is not really surprising as the typical network using Microsoft passwords back in the early 90's was a small office disconnected from the Internet. A man-in-the-middle would seem highly implausible and such an attacker would have been given physical access anyway. Enterprises with real needs for security generally ran Novell or a serious directory system anyway. It does not affect Kerberos/Active Directory authentication (coincidentally, Dan Geer's project), but sometimes those authentications can be downgraded to use NTLM.

This is also a cross-protocol vulnerability: there are more than a dozen protocols which can use NTLM authentication (most email, VPN, web, and file share protocols) and the attacker is free to mix and match client and server protocols because the forwarded credentials are compatible between them. Effectively there are over a hundred combinations of client and server protocols that may be vulnerable (or not) independently.

For example, Alice connects to insecure public wifi -> Mallory gets into corporate Outlook Web Access or SSL VPN portal. It's that bad.

When I came across this bug, I briefly wondered if no one else had understood the real implications before and if it might be some kind of zero-day. I'd remembered hearing about various NTLM issues over the years but didn't recall any fundamental changes since v2. So I did some clicking online and some asking around.

Amazingly enough, this vulnerability has been known on some level since 1996! It was talked about repeatedly at Black Hat conferences years ago, I think the security community considered it "beaten to death" by 2002. However, those researchers have tended to focus on one or two specific attack vectors (perhaps to make an effective demo) and the pervasive nature of the fundamental problem has not really "sunk in".

Consequently, mitigation efforts have been piecemeal. There were relevant patches in 1999, 2000, and 2001 (MS98-016, MS00-067, and MS01-001) but they just addressed some overly-specific cases. After that, little attention was paid to the bug for some time. But with the release of the exploit tool "Squirtle" and HD Moore incorporating the attack into Metasploit in 1997, new interest was found. Although these tools only demonstrate a few specific cases, it was apparently enough to prompt the development and release of six MS patches in 2008 and 2009, plus a few from other vendors. Yes, it's also a multi-vendor problem, Mozilla, WebKit, Samba, etc. can all use this protocol too.

Microsoft has made some initiatives to address the issue such as "SMB Signing" and "Extended Protection for Authentication". These are probably good steps to implement, but for a couple of reasons I feel they fall short of the mark. They are (yet again) protocol-specific mitigations for a cross-protocol problem which don't really get at the fundamental problem. Also, they are "optional" for either the client or server, so an attacker can most likely "opt out" of the protections! Unfortunately, this is the reality of backward compatibility in this case. As long as it remains possible to use an off-the-shelf client PC and to interact with a network storage device nothing more than a Windows username and password (i.e., not joining to any domain), then the attacker can emulate that least-common-denominator configuration.

So after a little research and talking to quite a few people, my impression is the only people who really understand the scope and severity of this problem are some bad guys, some pentesters, and a few engineers at various vendors. In this respect I feel the data security community has let the industry down. The Metasploit crew doesn't have the time and energy to write the finicky custom exploit code for every vulnerable configuration, but I would not make such an assumption about other teams of professionals.

Unfortunately, this status quo inherently favors the bad guys. I would like to see this change. Even if there's no simple solution right now, people at least deserve to know how owned they are. In the meantime there are probably some ways to limit one's exposure, e.g. turning off some features which may not be used anyway.

* Marsh Ray is a security researcher, hacker, and software developer with PhoneFactor.