Anyone with a basic understanding of Windows security knows that Microsoft LAN Manager (also known as Lan Manager, LanMan, or LM for short) has a pretty significant security vulnerability with regard to authentication. LanMan uses a really weak method of hashing a user’s password. The resulting hash is know as the LM hash and the method of hashing is referred to as the LM hash algorithm. What was intended to be a one-way function, as hashing is, turned out to be crackable with a few hours of brute force attacks.
With today’s advancements in technology finding a hash is relatively simple for an amateur. Additionally, with all possible hash combinations having been precomputed and stored in a format known as rainbow tables, it takes a matter of seconds to recover the password from a hash.
One of the best places to begin understanding the problem with the LM hash algorithm is to know the algorithm itself. According to Microsoft (Chapter 3 – Operating System Installation: The LMHash), the LMHash, is technically speaking not a hash at all. It is computed as follows (a few details spelled expanded on):
- The user’s password is converted to uppercase.
- This password is null-padded to 14 bytes and as such the user’s password is restricted to a maximum of 14 characters.
- The “fixed-length” password is split into two 7-byte halves.
- Note: Each 7-byte half is converted into a bit stream with the most significant bit first, and inserting a null bit after every seven bits (so 1010100 becomes 10101000), generating the 64 bits needed for DES keys.
- Each of the two halves are used as DES keys and used to DES-encrypt a specific ASCII string, “KGS!@#$%”, resulting in two 8-byte ciphertext values which are then concatenated to form the 16-byte LM hash.
There are several flaws with the algorithm itself. The first issue is that passwords are limited to a maximum of 14 characters; anything less is padded with null bytes to get you to 14, anything over 7 characters is split into two 7 character halves which are hashed separately. Next is this algorithm limits the password characters to a 95 character subset of ASCII printable characters; even worse is that since the passwords are not case sensitive, as all lowercase characters are converted to uppercase, this effectively reduces the 95 character subset of ASCII printable characters to 69 thus giving us a key space, for each half, of 69(7) ≈ 2(43). Finally the LM Hash does not use a salt, random data used as additional input, to defend against rainbow table attacks. This also makes the hash susceptible to man in the middle attacks and pass the hash attacks. Needless to say, all possible hashes have been pre-computed as Rainbow Tables making cracking of LM hashes trivial. (i.e. 14 char complex passwords are defeated in 3-11 seconds).
None of this is news to most people in the industry. Microsoft acknowledged the issue but instead of rectifying the problem came up with a series of pretty weak answers. NTLM was introduced in 1993, using the same 56-bit DES encryption and still no salting — pretty weak. This poor attempt at a fix was negated by the fact that Windows was still accepting LM responses in addition to NTLM responses, providing basically no additional security.
In 1998 with NT4 SP4 Kerberos became the authentication protocol as NTLMv2. This was released on NT 4 server only and as with NTLMv1, Windows was still accepting LM responses in addition to NTLMv1 and now NTLMv2 responses, providing basically no additional security. It wasn’t until 2000 that NTLMv2 was natively supported in a Windows Operating System, with Windows Server 2000. Microsoft adopted NTLMv2. finally reached clients when Windows Server 2000 was released in 2000. It also became available to clients with this release; natively with Windows 2000 workstation and as part of the Directory Services client for Windows 95 & 98.
Some ill informed naysayers may poo poo on the need to do anything because of NTLMv2, the ability to prevent LM hashes from being stored in Active Directory and in SAM databases on disk, as well as the ability to refuse LM and NTLM challenge responses. But is this really enough?
I am afraid it isn’t. The biggest concern is the false sense of security this provides. These “features” are not enabled by default on all systems and you can only wonder how many are still using LM hashes. I really can’t see many home users mucking around with Local Policy Settings (secpol.msc) to make these changes. The biggest flaw is that, despite any efforts you make to disable this, every time you log into your computer Windows calculates the LM hash for your password and stores it in system memory, for “possible” backward compatibility. Jump on a machine locally or remotely and you can dump the hashes of all logged in accounts directly from memory. From there all you need is up to 11s of your time and the passwords are compromised.
All is not lost though. If you think back to the beginning of this post and note what one of the key factors around LM hashing; the user’s password is restricted to a maximum of fourteen characters. Due to this 14 character limit we can simply create a password that is 15 or more characters, effectively breaking the LM hashing algorithm. When you use a 15 character, or greater, password the algorithm is unable to process the password into an LM hash and simply spits out a string of zeros instead as evidenced by attempting to dump the LM Hash out of memory.