Defending against pass-the-hash attacks

There is a nice article about this attack here http://en.wikipedia.org/wiki/Pass_the_hash. This is not a new attack as it was first described in 1997.  But it is a relatively obscure attack that is apparently little known, albeit very effective.

What happens with hashes is that Windows systems create these ‘unique identifiers’ and use them to identify users logged on to systems, so they don’t have to ask you for your password every time you try to do something more than open a window.  Anything system related requiring authentication, for instance, uses these hashes so you don’t have to reenter your password over and over.  In a way, it’s like cookies for web browsing if you will.

The issue is that the hash is used “as is” to authenticate a user, so if a hacker can get his hands on a hash, he doesn’t need to know the password anymore.  Instead of inventing systems to crack passwords, the hacker now simply needs to find a way to acquire those hashes and it’s all systems go.

Sounds easy but it isn’t; hashes only live in memory, and only for the time a user is logged on.   And they’re stored in an address space accessible only by the kernel, and only with administrative privileges.  The hacker needs to gain administrative privileges to be able to reach that memory.   The problem with that is, it is possible, and we all know how easy it has become with the many vulnerabilities and exploits we witness on a daily basis.

The real concern I see with this attack is that it doesn’t stem, like all the others we mention every day, from a vulnerability caused by a mistake in programming.  It stems from a problem inherent with the design of the system.

When you have a buffer overflow, it simply means that a programmer didn’t pay enough attention in protecting the boundaries of a variable and created a potential vulnerability.  Call it a mistake made by the programmer, if you will.  Someone will create a patch for this issue by modifying the vulnerable piece of code, deploying the patch, which will be installed on all the Windows systems out there (or so we hope), and that particular issue is gone.

With the pass-the-hash attack, there is no such fix.

Microsoft would need to redesign their authentication system entirely, from scratch.  In fact, NTLMv2 attempted to improve on the issue and correct some early naïve design; but even the new design is still vulnerable.  The only thing which is apparently not “yet” vulnerable is Kerberos, simply because no one has designed a tool to dump the equivalent of hashes (tickets) from Kerberos – yet. Will that happen or not, I’m positive it will, given time.

Why is this attack so important?

Because by dumping the hashes from memory, a hacker has instantaneous access to all the tokens necessary to logon as basically anyone he/she chooses, including the administrator if his hash was in the dump.  And that, of course, is like having the key to all the doors, without having to make the slightest effort to get them.  While password cracking can take time, hash dumping gives the hacker immediate access to anything those passwords were protecting.  That there is a huge reward for a rather small effort.  And tools are readily available on the internet – a hacker doesn’t even need to invent one from scratch.

How do you protect yourself from this?  There is an immediate solution; most AV tools recognize the known hash dumping tools and consider them malware; but if a hacker manages to write one that won’t be recognized as such, he might be able to circumvent ‘normal’ defenses.  The only way to truly stay safe is to adopt what Microsoft has called the least user access ~ meaning ‘use the user access privileges that will get the job done and don’t overdo it’.

Why do you logon as admin if all you need to do is list the files in a directory?  Easy to say, hard to do – especially if you ARE an admin and have no intention of remembering 20 different passwords, based on what task you’re up to.  We’ve all done that and we know what will happen – the admin will use the admin user name and password for anything.  And I frankly don’t necessarily blame them; imagine having to logon and logoff, over and over and yet over again, to escalate your own privileges!  Your job becomes way more complicated than it needs to be, and the reasons for doing all that may not be immediately clear to the admin anyway.

Obviously, if at all possible, upgrade your systems and stop using the older NTLM and LM; try to move to NTLMv2 as this makes it harder; move to Kerberos even if you can – but be careful, Kerberos isn’t used if you login using IP addresses; you must use NETBIOS names.

Never access your Domain Controllers from less protected systems; what happens in that case is that your DC password – the keys to your kingdom – are stored as hashes in that less protected system, and you’ve just put your entire network at risk!

The only method that truly hinders this attack is Two-factor authentication.  This method is good not only because a password isn’t enough to get in; it’s also because the hash alone won’t allow access.

This great paper by The SANS Institute http://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283 further explains the topic, and provides more pointers on what else can be done to try and stay safe.