This article is part of the series "A Closer Look at Pass the Hash". Check out the rest:
I was about ready to wrap up this series of posts on PtH and make my larger point, which is that you should assume hackers will break into your system and then I learned new information about credential stealing that amplifies this warning by a factor of 10.
The most important takeaway about PtH is that the password hashes that are stored in memory (and grabbed by hackers) are a feature of Single Sign On. Most organizations can’t live without SSO, so they’re stuck with PtH risks. I already blogged about ways to reduce these risks, but they can’t altogether be eliminated.
Get the Free Pentesting Active
Directory Environments E-Book
More Features to Worry About
There’s another underlying feature that also has to be taken into account. Existing Windows authentication protocols, which directly use the password hash, have had a long history of problems. As of January 2013, Microsoft’s official line on NTLM, their workhorse logon authentication software, is that you should not be using version 1—the newer v2 is better (but still has some vulnerabilities).
By all means, if feasible, jump from NTLM to Kerboros, which will greatly reduce your security exposure. But many IT groups can’t completely cut their ties to NTLM—mostly because lots of client apps (email, browsers, VPN, file sharing) still depend on it. And then there’s SAMBA, a suite that provides Windows file and print services for UNIX/Linux, which also uses NTLM.
Bottom line: NTLM has deep hooks into Windows.
But even more troubling—and here’s one piece of new information I learned from security blogger Mark Gamache—is that there’s an enormous security exposure because of all the XP out there—at least 20% of all computer based on W3 data. And these legacy clients’ can only default authentication is—you guessed it—NTLM version 1.
A Little NTLM
To understand what’s wrong with NTLM, we need to know a little more about how its challenge-response works.
Rather than write out a geeky protocol syntax, the interaction (for version 1) can be roughly summarized by the following dialogue:
Server: Hi. I know you’re claiming to be user XYZ, but you’ll need to prove it. But don’t tell me the password out loud—someone will overhear! Instead, I want you to take this challenge: encrypt “swordfish”, and then tell me the results. You can use DES.
User: And what key should I use for DES?
Server: The MD4 hash of your password—use that.
Client: Ok, I’ve encrypted “swordfish” with the password hash and I have weird 24-byte string. Is that what you want?
Server: Yes
Client tells server the encrypted string. And server compares with its encryption of swordfish, which matches.
Server: You are worthy, please enter!
The most important improvement in NTLMv1 over an even earlier Windows authentication method, known as LM, was not directly sending the password over the wire. Instead, encrypting the challenge with the hash of the password is proof that the user is who he/she claims to be.
The initial version of NTLM dates back to pre-internet NT systems—it stands for NT LAN Manager. Certainly, a more innocent time—circa 1990s—where the assumption that no one could get into an office LAN and launch crafty relay or man-in-the-middle exploits was a good one.
That was then. NTLMv1 eventually became susceptible to a style of attack wherein users were redirected to connect to a rogue server—you can read more about that here. The server would send a challenge for which it had already pre-computed the hashes for zillions of passwords and stored the encrypted challenges in a giant dictionary.
If the fake server finds a match, it then automatically has the password hash for that user.
NTLM Is Really Broken
In response, Microsoft improved the challenge-response protocol in NTLMv2 to prevent these server-based dictionary attacks. However, it still left open the possibility of man-in-the-middle exploits, as well as PtH.
But up until recently, you could make a case for staying with v1.
In 2012 some astonishing news came out of a Defcon conference. Using special purpose-built hardware, security researchers had succeeded in cracking the DES encryption used in the NLTMv1 challenge-response exchange.
In other words, by watching the wire and grabbing the packets containing the challenge text from the server and the encrypted DES response, hackers could, through a brute force approach, work out the key— i.e., the underlying password hash. Yikes! And then some researchers made this DES cracking capability available as a service, known as OnlineHashCrack, for penetration testers!
I don’t want to get too much into the weeds about the fatal flaw in NTLMv1. In short: NTLMv1 doesn’t use the full 128-bit output of the MD4 hash as a DES key, but smaller 56-bit groupings, thereby making the client response amenable to being cracked by a powerful computing device. By the way, NTLMv2 uses a longer key but with a different encryption algorithm, HMAC-MD5—technically a one-way hash function.
And Going Forward
This crypto-news eventually made its way to Microsoft, which then issued the NTLMv1 warning I mentioned earlier.
So what’s a reasonable next step considering all this? The first action for IT is to review current LAN authentication levels (in GPO or within Local Security Policy). It’s not unusual to have set NTLMv2 as default, but still allow clients to negotiate NTLMv1 or the still older LM. If it’s feasible, they should set the “refuse LM and NTLM” option. 
NTLMv2 is—as far as we know and assuming you’re not dealing with the NSA—immune to cracking. The caveat here is that user passwords are long enough—at least 8 characters—otherwise even this new version may be vulnerable to brute force approaches. So another ‘to do’ on your list is to really enforce a strong password policy across the organization.
The v2 challenge-response protocol can still, though, be tricked by sneaky servers getting in the middle and relaying credentials from a client to an authenticating app. And v2 doesn’t do anything to prevent PtH attacker from grabbing credentials.
Here’s a simple rule of thumb based on all this: assume the hacker will get in.
You therefore need a solid ‘Plan B’ defense strategy. In my previous PtH post, I recommended disabling remote access rights for ordinary users to prevent hackers from harvesting credentials by hopping on to other machines. It’s a good idea, and even more so considering all this new information.
Your final defensive wall should, of course, be business-as-usual data governance practices—monitoring, alerting, etc.
And you do that, as the Metadata Era has pointed out on many occasions, by finding where PII and other sensitive data is located, determining the true data owners, making sure the owners limit access to those who truly need it as part of their job or role, monitoring use and using automation to detect possible abuse. So when the hackers enter the site, they’re not coming in as if they “own the place” since they no longer have easy access to troves of sensitive data.
