etwork has clients that require the LAN Manager protocol, such as Windows 95, Windows for Workgroups, or regular Windows 3.1, anyone with the right tools can intercept the obfuscated user names and passwords, and extract their plain-text equivalent.
A white paper by the researcher known on the Internet as hobbit started it all, analyzing bit by bit the CIFS protocol used by NT. Dominique Brezinski of Cybersafe then released a paper that concentrated on the man-in-the-middle problem in the process. From down under, an anonymous
Australian programmer released the source that allowed the programmatic deobfuscation of LAN Manager and NT hashes from the NT registry.
Cygnus programmer Jeremy Allison quickly cleaned it up and released PWDump, which was meant to be a password audit tool for NT. PWDump unleashed a storm of controversy after it was incorporated in a Trojan horse by a Bay Area-based programmer. Later, the hacker group that's known as the L0pht built a sophisticated brute-force password cracker that extracted plain-text passwords from the PWDump hashes.
NT's security is based on two cryptographic methods: the IBM-sired LAN Manager security protocol and the NT security protocol. While each has strengths and weaknesses, together they prove to be disastrous, because the weaker LAN Manager protocol emasculates the stronger NT protocol. Unfortunately, because of backward-compatibility requirements, Microsoft continues to use the weak LAN Manager protocol.
Why is the LAN Manager protocol weak? It's the implementat
ion. In a nutshell, LAN Manager hashes the passwords in a predictable way and does not use salting (the process of inserting several random bits into the hash).
From our research, we have found that you have to go through only seven characters to retrieve passwords (up to 14 characters in length) in the LAN Manager hash. Also, because no salting is being done, constants show up all over the place, giving away too much information and speeding up attacks tremendously.
The first 8 bytes are derived from the first seven characters of the password, and the second 8 bytes are derived from the eighth through fourteenth characters of the password. If the password is less than seven characters, the second half is always the same.
Let's assume for this example that the user's password has an LM hash of -0xC23413A8A1E7665fAAD3B435B51404EE (I will save everyone the nanosecond it would have taken for them to plug this into L0phtcrack and have it tell them the password is "WELCOME").
The following
is what happens to this hash on the network:
System B sends an 8-byte challenge to system A. (Assume 0x0001020304050607.)
Machine A takes the hash of 0xC23413A8A1E7665fAAD3B435B51404EE and adds five nulls, thus becoming 0xC23413A8A1E7665fAAD3B435B51404EE0000000000. This string is broken into three groups of seven.
The 7-byte strings are str_to_key'd (if you will) into three 8- byte odd-parity DES keys.
Then, 8byteDeskey1 is used to encrypt the challenge 0x0001020304050607. Let's assume the result is 0xAAAAAAAAAAAAAAAA.
Next, 8byteDeskey2 is used to encrypt the challenge 0x0001020304050607. Let's assume the result is 0xBBBBBBBBBBBBBBBB.
Next, 8byteDeskey3 is used to encrypt the challenge 0x000102-0304050607. Let's assume the result is 0xCCCCCCCCCCC-CCCCC.
The three 8-byte values are concatenated (dumb), and the 24-byte response of 0xAAAAAAAABBBBBBBBCCCCCCCC is returned to the server. The server does the same thing to the hash on its end and compares the result to the 2
4-byte response. If they match, it was the correct original hash.
Why is this weak? The first thing we check to see is if the user's password is less than eight characters in length. We do this by taking the 7-byte value of 0x04EE0000000000, turning it into an 8-byte odd-parity DES key, and encrypting it against the 8- byte challenge of 0x0001020304050607. If we get the result of 0xCCCCCCCCCCCCCCCC, we are pretty sure it's fewer than eight characters in length.
To be sure, we can run through 0x??AAD3B435B514 (i.e., 256 possible combinations) to see that 5f shows us that the result is 0xBBBBBBBBBBBBBBBB, proving that the password is less than seven characters and also giving us the last byte of the first half of the LAN Manager hash.
Note that we're not worried about optimizing the way this is done, and that there are much more effective ways to do this that reduce the amount of time required even further. Even so, this shows that even a simplistic attack works against this implementation, an
d it's no different than how a tool such as L0phtcrack attacks the hashes in the registry.
What if the password is eight characters or more? Let's say that machine A takes the hash of C23413A8A1E766AC435F2DD90417CCD6 and adds five nulls to it, thus becoming C23413A8A1E766AC435F2DD90417CCD60000000000.
The first thing to check is if the password is fewer than eight characters in length. Deriving the 8-byte odd-parity DES key from 0x04EE0000000000 and encrypting against 0x0001020304050607 does not, in this case, give us 0xCCCCCCCCCCCCCCCC, so we know that the password is eight characters or greater.
It takes us, in a worst-case scenario, 65,535 checks to figure out that the 2 bytes that are used in the last third are 0xCCD6.
You can go through your seven-digit combinations of characters for the first third the same way you would the LAN Manager hash from the registry. This will yield not only the first third of the response, but also the first byte of the second third. Keep in mind that y
ou already have the last 2 bytes that made up the final third. You can approach the middle third in the same fashion.
Together, these problems enable utilities such as L0phtcrack to get and decrypt passwords quickly using brute-force methods.
Because opting out of the LAN Manager security model precludes continued use of Windows 95 machines as clients to NT machines, it is still a moot point as to how tough or well done the NT hash might or might not be.
Password Protection at a Price
