A Closer Look at Pass the Hash

[Nytro]

A Closer Look at Pass the Hash, Part I

Posted by: Andy Green

We’ve done a lot of blogging at the Metadata Era warning you about basic attacks against passwords. These can be mitigated by enforcing strong passwords, eliminating vendor defaults, and enabling reasonable lockout settings in Active Directory. But don’t rest yet! Hackers have another password trick that’s much more difficult to defend against.

Advanced password, or more precisely, credential attacks are still very popular and, unfortunately, quite effective. Known generically as pass-the-hash or PtH, these attacks are seen by some as more of an issue with older Windows systems. Somewhat true, but they’re still very much a menace: PtH is the subject of presentations at recent Black Hat conferences, several white papers from Microsoft’s own Trustworthy Computing division, and a security bulletin from the NSA (for what it’s worth!).

What’s a Hash?

Security researchers have known almost since the beginning of modern computing that storing plain-text passwords is a poor security practice. Instead, they came up with the idea of passing the plaintext string through a special 1-way encryption function to produce a hash. You can read more about hashes in Rob’s excellent posts on the subject.

The key point is that in both Windows (and Linux systems too) the hashed password is stored instead of the readable password. If you think about this a little, the hash acts as a proxy for identity—if you can prove you have it, it’s your ticket in.

In Windows, the NTLM authentication protocol involves exchanging messages to validate that users have the hash without actually sending the hash over the wire. This authentication technique is at the center of how Active Directory supports remote logins within a domain and is also used for other Windows services, most significantly remote file access

By the way, vulnerabilities in earlier implementations of NTLM—since corrected—have led some to believe that PtH attacks are a thing of the past. Not only is PtH still viable but the same idea—grabbing hashes from disk or memory—can also be used against more sophisticated Kerboros authentication.

Don’t Crack the Hash, Pass it

Windows caches the hashed passwords in memory to implement Single Sign On or SSO, which is an essential feature of Windows enterprise environments. So far, so good.

For example, on my Varonis laptop, I logon once with my password, Windows hashes it and stores the code—currently 128-bits in NTLMv2— in memory so that when, say, I mount a remote directory or use other services where I need to prove my identity, I don’t have to re-enter my password— Windows instead uses the cached hash.

And that is enough of an opening for hackers to exploit. We’ve seen other attacks, most significantly with RAM scrapers used on Point-of-Sale devices, where hackers use easily available software to peek into this memory. Not surprisingly there are toolkits out there that will let hackers grab the credentials from memory, and log them in as that user—see SANS’ Why Crack When You Can Pass the Hash.

And that’s one of the major benefits of SSO, so to speak, for hackers: they don’t have to crack the hashes, they just re-use or pass them to an authenticating server!

PtH: It’s a Feature, Not a Bug

The assumption that this attack makes is that the cyber thief gains administrator-level permissions for a user’s machine. Any expert will tell you, that’s not necessarily difficult to pull off, as we’ve seen in the Target hack.

In a typical exploit, the hacker will grab some hashes, log onto other servers, and continue the process of stockpiling credentials. If they hit the jackpot—a domain controller or SQL server—they may able to get the hashes of just about everyone.

As an aside, we don’t know exactly how Snowden obtained employee logon credentials—social engineering likely played a part. But his admin-level access would have made PtH a very good choice to extract the credentials of those with a higher security clearance than him.

Unfortunately, pass-the-hash is a feature of Windows! After all, the underlying NTLM authentication is effectively passing the hash to implement SSO, saving you from password entry fatigue. Hackers are just exploiting this feature for their own purposes. Not to be too hard on Windows, PtH is also an issue in Linux systems that implement Kerboros , where you have an equivalent pass-the-ticket or PtT attack.

Here’s the most important takeaway: you can’t prevent PtH, you can only mitigate or greatly reduce the possibility of this attack occurring.

Hold that thought and we’ll take up PtH mitigation through smart configurations of Active Directory and other services in the next post.

Image Credit: Mattia Luigi Nappi

A Closer Look at Pass the Hash, Part II: Prevention

Last week, I attended a webinar that was intended to give IT attendees a snapshot of recent threats—a kind of hacker heads-up. For their representative case, the two sec gurus described a clever and very targeted phishing attack. It led to an APT being secretly deposited in a DLL. Once the hackers were in, I was a little surprised to see they were probing memory for password hashes.

Pass the Hash, or PtH, I learned, was a standard hacker trick for gaining new identities. It makes sense. Hackers prefer to use credentials taken this way and logon directly as a user, rather than using more roundabout C2-style backdoors. Without sophisticated monitoring in place, they’re less likely to be spotted in real-time or even forensically afterwards when appearing as an ordinary insider.

Beware of Local Admin

As I mentioned last time, PtH assumes that an attacker has admin-level privileges on the machine they’ve first entered. The hash, which is kept in the memory space of a process with local admin permissions, is by itself not used to establish identity. Instead, it becomes part of a secret key for encrypting and decrypting messages in a challenge-response protocol.

In effect, you need just the hash code to take over the identity of another user. The hard part is getting local admin access.

Unfortunately, this is not a major hurdle. On older Windows systems (pre-Vista), the local admin account is automatically created and even worse, IT may have given each user machine the same admin password.

Suppose a laptop is compromised through a phish-mail that deposits malware. The malware succeeds in a brute force assault on the local admin passwords. From this machine, the hackers can leapfrog to other devices and servers, either through new credentials that’ve been scooped from memory by PtH toolkits or by simply reusing the admin password.

It may be an annoyance for admins, but UAC is a good defense against PtH.

Thankfully, newer Windows OSes—Windows 7 and 8—by default don’t create a local admin account. Even better, Microsoft added a new malware defense known as User Account Controls or UAC, which requires explicit authorization for a user (or software) to gain elevated privileges.

Admins know UAC through the Consent or Credential prompts (see pic) that pop up when they do legitimate work. While they may find this somewhat inconvenient, it does go a long way towards preventing malware and APTs from getting a critical foot hold.

For organizations with older OSes, IT can enforce a policy of creating unique and robust admin passwords for each user machine. It’s a low-effort remedy for preventing the hackers from easily guessing admin credentials and then reusing hashes on other machines. One simple trick is to append the machine name (or variation of it) to the password.

Stomp Out Local Network Logon Access

Another powerful mitigation that works on both old and new Windows OSes is to prevent ordinary and local admin users from directly networking into other users’ machines. In an Active Directory environment, you’d do that by using the Group Policy Object (GPO) Editor to configure a User Rights Assignment networking policy. You can read more about how to do this here.

Quick summary: disable network and remote interactive logon privileges and then link users and groups to these specific User Rights policies.

And Just Limit Hashes

The above measures take care of a large part but not all the entry points for PtH attacks. In the exploit that I opened this post up with the hackers used SQL injection techniques to hijack a database server that was already running with elevated privileges. Result: they were able to scoop up high-level hashes.

The least privilege security principle now comes to the fore: don’t run services—SQL servers, and other IT infrastructure—with domain or enterprise level access rights. These permissions are far broader than what system tools and services generally need to do the job, and if the software is ever compromised, the shells or commands that are spawned automatically run at elevated access.

However, sometimes this may not be feasible, and of course, there are always zero-day exploits waiting to happen. So the key idea now is to limit the “bad” hashes—typically domain administrators—from spreading throughout the network. Recall that with Single Sign On, the hash, even for DAs, is always deposited in memory when logging onto a machine.

The rule is simple: only give domain administrators the right to access machines with high-privilege levels—i.e., domain controllers—and never allow the same accounts access to plain-old employee laptops and desktops. You can always create a separate account for system admins for servicing user devices but with non-domain admin privileges.

That way, if a hacker (or internal user) should ever get control of a machine, they’ll never get the “keys to the kingdom”—a domain administrator’s hash that just happens to be in memory at the time.

A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it)

I was about ready to wrap up this series of posts (part 1, part 2 ) 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.

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 authenticate with—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 the researchers made this DES cracking capability available as a service, known as CloudCracker, 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 use a full 128-bit key.

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 DES cracking. The caveat here is that user passwords are long enough—at least 8 characters—otherwise even this new version is also vulnerable to DES 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.

Surse:

1. A Closer Look at Pass the Hash, Part I

2. A Closer Look at Pass the Hash, Part II: Prevention

3. A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it)

Edited July 15, 2014 by Nytro