The first question one might ask is, “Really… Why are
you writing about this old news now?” The answer is simple; even with the
release of Window 8 and Server 2012, Pass the Hash (PTH) attacks are still
incredibly simple and effective. While from an academic standpoint
passing the hash is simple to understand, it is a bit more complex from an
attacker or defender’s stand point. The reason for this post is that
having read a huge number of papers and post on pass the hash, none of them
gave me a clear picture.
The reason pass the hash is so powerful is due to NTLM’s
initial design flaw. NTLM was essentially broken from the day it was
released. While UNIX started saving salted hashes in the 1970s, the
designers of NTLM chose to use an unsalted hash. Salting a hash is
probably the most important design criterion when designing an authentication
system.
A hash
is a one way transformation of a variable input to a fixed length output.
A hash function must be deterministic, meaning that the same input will always
generate the same output, no matter what platform it might be run on. Another
key property of a good hash function is that even a small change in the input
creates a significant change in the output. The final vital property of a
hash function is that it must be truly one way. There must be no method
allowing the input to be derived using only the output.
With these properties, and the benefit of hindsight, a hash
is the perfect way to for one party to prove they know a password without the
other party actually knowing it. Storing reversible or god forbid
plaintext passwords introduces a significant number or risks. Only the
ignorant do this.
If the hash can’t be reversed, then you might think there
are no more risks and you can just hash those passwords and be on your merry
way. If we didn’t have a security model to think about, this might make
sense. The reason we bother to hash the passwords and not store
them as plaintext on our authentication servers is that, on the off chance that
the auth server is compromised, we want to minimize the value of the stolen
identities. Assuming you kick out the attacker and restore from backup, it
would be nice to not have to force all of your users to change their
passwords. It would be nice to be sure that the breach wasn’t just a
foothold to a larger attack. Additionally, as users tend to reuse passwords, we
don’t want to put the users’ accounts at risk on other systems or sites.
This brings us to the risk created by just storing the password hash with no
salt. If one has access to the hash and wants to derive the input
(password), all that needs to be done is test passwords until the outputs (hashes)
match. This Brute
force method is always a theoretical option when trying to defeat a
cryptographic function. Trying all possible passwords is time consuming,
which works against the attacker. Unfortunately, with super fast
processors and huge amounts of cheap storage, it is now possible to pre-compute and store huge
numbers of hashes and the corresponding passwords. In the space of less than 1 TB, you can
store tables that cover 96% of 1 to 9 character passwords containing upper
case, lower case, and numbers. By storing just the password hash we make
it completely worth an attacker’s time to create and save the pre-computes
values. Even better, you can just pay when you need to use
someone else’s’ tables.
Simply salting the hash wastes all that work the attacker
did to pre-compute the hashes. Salting a hash is simply adding random or
pseudo-random data to the input before computing the hash. The salt is
saved and later used when verifying the password. When verifying the
password, the salt is looked up, re-applied to the password that is being
tested, and the data hashed. If the result on file and the real-time
computed result match, the password was correct. By applying the random data,
we have completely wasted the attackers’ pre-computation effort. Ideally,
every account uses a different salt, so that even if your user database is
taken, every password must be brute forced separately.
Salted Hash Example
Password Salt SHA-1 Hash
V3ryStrong 1 88 93 EB 7A 28
DA A4 95 89 B1 B5 A1 E0 C6 A0 83 9D 38 A3 39
V3ryStrong 2 59 86 41 B2 62
B7 C3 C7 54 27 78 94 FB D6 59 24 5F 77 74 40
The example is purposely weak to make for easy
understanding. Usually the salt would be 8 – 16 bytes. It shows the
amplification provided by SHA-1. With a single bit change the data is
completely different and we see that there is no way to pre-compute all
passwords, unless we pre-compute all passwords with all possible salt values,
which in not feasible.
While this is fun background data, it really has little to
do with passing the hash, as PTH lets an attacker who has the hash assume the
user’s identity without ever knowing the password. This is because
windows stores the user’s NT hash in Active Directory DIT
or the SAM.
The first step of NTLM and NTLMv2 handshakes is that the system converts the
user’s password to the NT hash, and the handshake does some fun handshake math
that proves the user knew the hash, without the hash ever crossing the
network.
This system makes the hash “password equivalent”. If
an attacker has the user’s hash, they just skip the “convert password to NT
hash” and go straight to using it in the handshake. There are many
tools for doing this, depending on where NTLM is being used. NTLM
authentication occurs in-band with the protocol that is being used to access
data or access a system. NTLM auth occurs inside remote file access via
CIFS/SMB, TDS for accessing SQL server, RPC for all sorts or remote
administration and access, HTTP
for web auth, and I’m sure a few more things.
In order for an attacker to pass the hash, they need four
things:
1.
The valid NT hash (and username)
2.
A channel to pass the hash through
3.
A server hosting a service that utilizes/allows NTLM auth
4.
A client (or tool) that allows the attacker to input the hash rather
than the password
In a world where all four elements are available to an
attacker, there is no stopping PTH. Keeping in mind the four
requirements, defenders can limit, and more importantly, and understand their
level of exposure.
Securing the Hash
The most important thing a defender can do is keep the hash
from falling into the wrong hands. The hash resides on a computer in two
main areas; the SAM (Security Account Manager) db and in RAM, for users that
are logged in. There is a common misconception that the NT hash is also
stored in the registry for cached logon of domain user accounts on domain
joined computers. This is just that, a misconception. Depending on system
settings, data is stored that allows a domain user to logon to a machine when
no domain controller is available; however this data is an MD4 of
the NT hash + username. It might be worth an attackers’ time to
pre-compute the hashes for common user names, such as ‘Administrator’.
Looking at the threat model, one can conclude that the horse
is out of the barn if the hash is stolen. In order to steal the hash, the
attacker had to gain full control of the system. The attacker must either
execute hash stealing code as a member of local administrators, or gain
physical access to the poorly protected computer. While the horse is
indeed out of the barn on that host, the attacker should be able to go no
further. At least that is the defenders hope. This is, of course, not the
case. If the user has the other three required elements, she can act as
the user at will.
Stealing the Hash from RAM
In order for an attacker to steal a user’s NT hash from RAM,
the attacker must run code with administrator rights. As with all the
advice that will be offered, all the controls are fairly standard and map to
basic security concepts.
·
Reduce surface area
o Don’t
leave sessions logged in unnecessarily, as another administrator’s failure can
compromise your account.
o Avoid
logging in with administrator rights. If you screw up and run attackers
code, they can’t steal the hash if you aren’t an admin.
·
Use up to date AV software
Stealing the Hash via Physical Access
We all know that if an attacker has physical access
to a host then they own the host. The last thing we want to do is allow the
attacker to use that host as a foothold to even more systems and data. In
the case of PTH attacks, we probably have good news here. The NT hashes
are stored in the local SAM. If the computers are not domain joined, the
username and password usually don’t cross hosts, unless you took the time to
sync up your usernames and passwords across them all. As I mentioned
earlier, the cached domain credentials DO NOT contain the NT hash. This means
the SAM from one computer is of no value on anther.
The one place where there IS a great deal of risk is in an
enterprise, where standardization probably means that the local admin password
is the same across every domain member. This means that the
compromise of any one server is equivalent to the compromise of every
server. This means that that dev server that you left up running PHP 1.2
can be a great foothold to the rest of your servers and data.
To reduce this risk:
·
Use full disk encryption that requires a token or Password Based Key
Derivation Function
·
Enable syskey
protection > 1.
o This
requires a password or floppy to boot and decrypt the goodies in the SAM.
o This
scales poorly for an enterprise.
·
Make sure all local admin passwords are different.
Stealing the Hash from the Network
The NTLM and NTLMv2 handshakes assure that the NT hash
itself can be verified, without it ever appearing on the network. There
is nothing to see here.
If an attacker were to figure out a way to get the hash from
the network, it would be an impressive feat.
Securing the Channels
If the attacker steals the hash, but has no path to pass it
over, then the hash is of little value. One nice thing about NTLM auth is
that it occurs in band with the protocol utilizing it, so as a defender, you
can better understand and limit your exposure. If you block ports 80,
138,139, and 445, but open 1433, you know that the stolen hash can only be used
to access SQL data but not remote file access or websites.
Controls to consider:
·
Reduce Surface Area. Only open the ports you need. Duh…
·
Authenticate end points with VPN or IPSec.
Stop using NTLM
This one is not so simple. One can “kerberize” all
sorts of servers. That is, allow them to utilize Kerberos authentication
rather than NTLM. Microsoft has done a pretty good job kerberizing
applications, but in almost all cases, if Kerberos fails, the app will allow
fallback to NTLM.
I know of no options for a defender here. This section
is really a call to MS, and others, to allow for more granular options related
to NTLM auth, Kerberos, and fallback options.
I suppose this is an opportunity for firewall vendors as
well. It would be fairly easy to block NTLM auth and allow Kerberos on a
per protocol basis. I suspect an F5 ninja could write a crazy iRule to do it too.
Stop Clients from Allowing the use of the NT Hash
Assuming you have dealt with the firewall rules, most
attackers will have no channel to pass hashes over. The last option would
be to pass from hosts inside your network. This seems plausible, as the
attacker got enough access to steal the hash.
There are two classes of tools that let you work from the
hash rather than the password. The first are tools like WCE,
which run on windows and allow an administrator to inject arbitrary usernames
and hashes into a user’s session. This allows all subsequent uses of any
tool in that session to authenticate as the injected user. This means
that any Windows tool that speaks NTLM will work. The second class are
custom tools that may run on any OS and speak the protocol in question, be it
SMB, TDS/SQL, RPC, or whatever, AND they speak NTLM taking a hash rather than
password.
For a good list of current tools and tons of great info on
PTH, see Still Passing the Hash
15 Years Later.
A good list, granted probably dated, of AV test results for
detection of the tools, can be found here.
Controls to consider:
·
Make sure EVERY host inside your firewall has up to date AV.
o Enforce
this with NAC
or NAP.
o Make
sure hosts with AV match up to your CMDB, such that all hosts are accounted
for.
·
Consider AppLocker
and Software Restriction
Polices.
o Make
sure to block known tools by hash so the attacker can’t just rename at tool
o Make
sure to block known tools by name, in case the attacker makes code changes but
chooses to use the same executable name.
o Consider
white listing known good apps rather than trying to blacklist known bad ones.
·
Minimize the number of local administrators. A local admin can
stop AV or add exclusions prior to copying over and loading up tools.
·
Keep up on the latest version of the tools and test your AV yourself.
Understanding Why Pass the Hash Still Works
The best way to learn this stuff is to go to Eric Glass’s NTLM page
and do the math along with him. I am borrowing heavily here to summarize
for lazy. ;-) Well, there is a lot more great stuff on his page
that you don’t need to know to understand PTH.
There are three different types of NTLM responses:
1.
NTLM
Response
2.
NTLM2
Response, not to be confused with NTLMv2 Response
3.
NTLMv2
Response
NTLM Response
1.
Convert password to Unicode and apply MD4 hash. This is the NT
hash.
2.
Pad the NT hash with 0s to make it 21 bytes.
3.
Break the 21 bytes in to 3 keys of 7 bytes each. This is 56 bits.
4.
Apply odd parity to each key. This makes each key a valid 64 bit
DES key.
5.
Encrypt the NTLM challenge (from the server) with each of the three
keys.
6.
Concatenate the three encrypted values, creating the response.
7.
Send it.
As you can see, the challenge is provided by the server, and
could be substituted by an attacker with network access. This allows an
attacker to create pre-computed responses (rainbow tables) for that
challenge. Obviously this is scary.
NTLM2 Response
Once again, not to be confused with the NTLMv2
Response. This one uses nearly the same math as the NTLM Response, but
let’s the client add a “client challenge” thus negating the value of an
attacker substituting their own challenge. This is used when the
0x00080000- NTLM 2 session security flag is set.
1.
Convert password to Unicode and apply MD4 hash. This is the NT
hash.
2.
Pad the NT hash with 0s to make it 21 bytes.
3.
Break the 21 bytes in to 3 keys of 7 bytes each. This is 56 bits.
4.
Apply odd parity to each key. This makes each key a valid 64 bit
DES key.
5.
The client creates a random 8 byte client challenge.
6.
The server challenge and client challenge are concatenated and MD5 is
applied, creating the challenge data.
7.
Encrypt the challenge (MD5 output) with each of the three keys.
8.
Concatenate the three encrypted values, creating the response.
9.
Send it.
NTLMv2 Response
This response is next level. It is totally different
that the first two and includes a timestamp, the domain the user belongs to, as
well as target information.
1.
Convert password to Unicode and apply MD4 hash. This is the NT
hash.
2.
Concatenate the upper case Unicode username with the Unicode
authentication target.
3.
Perform HMAC-MD5 on the result of step 2, using the NT hash.
4.
Construct blob, containing the Blob signature, 4 bytes of all 0s, the
time in NT time format, the client challenge, another 4 bytes of all 0s, and
the target information from the server Type 2 (challenge) message, and another
4 bytes of all 0s.
5.
The server challenge form the Type 2 message is concatenated to the blob
from step 4.
6.
The blob from step 4 is then HMAC-MD5’d using the result of the HMAC-MD5
in step 3.
7.
The HMAC response from step 6 and the blob from 4 are concatenated and
constitute the response.
8.
Send it.
Conclusion
Pass the hash attacks are alive and well and are not going
away anytime soon. Protect your systems.
