Use NTLMv2 to prevent cracks on authentication
When Microsoft decided to make Windows NT backward compatible with LAN Manager, I wonder whether the company realized the security problems that backward compatibility would cause. This decision certainly eased the implementation of NT for existing LAN Manager environments and for sites with Windows 95, Windows 3.x, DOS, and OS/2 installed because you can take advantage of the LAN Manager client software already present in those client OSs. But backward compatibility caused NT to inherit some significant security weaknesses from the way LM—the LAN Manager authentication protocol—hashes passwords and authenticates the network. (For information about LM authentication weaknesses, see "Protect Your Passwords," October 1998.) LM authentication uses a challenge/response mechanism for logon to eliminate the need to transmit the password over the network. But LM's vulnerabilities let intruders eavesdrop on a network segment, capture the challenge/response, and crack the logon. NT has the same vulnerabilities because, to support pre-NT clients and servers, it automatically sends and accepts the LM responses, which is a dangerous weakness.
Posing a threat to NT is L0phtCrack, a popular password-cracking tool from L0pht Heavy Industries. L0phtCrack comes with a challenge/response sniffer that can capture logons as they occur on the network. Using these challenge/response pairs, L0phtCrack further exploits LM's weaknesses to recover the actual password. L0phtCrack 2.5 has an enhanced GUI sniffer integrated into the main L0phtCrack engine, as Screen 1 shows. The new GUI sniffer, SMB Packet Capture Output, eliminates the need for a special packet driver, which the previous version required. This shrink-wrapped tool lets even novice intruders easily learn the passwords of everyone logging on to the intruder's network segment.
Before Service Pack 4 (SP4) came along, systems administrators needed to combat this problem with the post-SP3 hotfix—lm-fix. Lm-fix added the LMCompatibilityLevel Registry setting so that you could instruct NT not to support LM authentication, thereby defeating the L0phtCrack sniffer. However, this scenario meant you could use NT only on client workstations because Win9x, Windows 3.x, DOS, and OS/2 support only LM authentication. Unfortunately, lm-fix caused some stability problems, so Microsoft removed it from the Web. The removal of lm-fix left administrators without a fix for a serious problem.
When SP4 came out, I was anxious to verify that Microsoft had included lm-fix's functionality. What I found was a revision of the network authentication protocol NTLM, which Microsoft designed specifically for NT to improve security. NTLMv2 has several enhancements that address authentication problems and session security requirements for confidentiality, integrity, and 128-bit encryption. In this article, I explain NTLMv2's options and make you privy to several undocumented details and bugs that are crucial to security. I also discuss how each option stands up to attacks from L0phtCrack 2.5 and address possible future attacks. Finally, I finish up with practical recommendations for implementing the best security while preserving compatibility.
Background of NTLM Authentication
When a user needs to connect to a server, the server authenticates the user with a challenge/response protocol. The server issues a random string of bytes called a challenge to the client. The client encrypts the challenge with the hash of the user's password and sends the encrypted challenge back as the response. The server decrypts the response with the official password hash stored in the user's account. If the decrypted response matches the original challenge, the user is authentic.
NT clients send two responses in reply to the server's challenge: the LM response and the NTLM response. Because the client sends both responses, the NTLM hash and response are irrelevant. But the LM response lets NT connect to or accept connections from non-NT systems including the downlevel systems: Win9x, Windows 3.1, DOS, and OS/2. When L0phtCrack captures an authentication, the tool displays the responses in two separate columns called the LanMan Hash and the NT Hash, as Screen 2 shows. Originally, these columns held their correspond-ing response types. Since lm-fix, these columns have different response types than you might expect because of Microsoft's creation of new LM response and NT response versions for security and backward compatibility. In NTLMv2, the Registry value LMCompatibilityLevel controls the authentication enhancements, and LMCompatibilityLevel has enhanced functionality.
Authentication has a few other problems to keep in mind regarding pass-through and local network authentication. Because NT and downlevel systems can be clients, servers, or both clients and servers, an NT server can be a member server and also a domain controller. When a client connects to an NT or downlevel server using a domain account, that system doesn't perform the authentication but forwards authentication to the domain controller. This process is pass-through authentication. Otherwise, when a client connects to a server using a local account or share-level security (possible with downlevel OSs), that server must use the local SAM to handle the authentication. This process is local network authentication. As I later explain, pass-through and local network authentication further complicate Microsoft's efforts to minimize NT's network authentication vulnerabilities.
L0phtCrack Threatens NTLM Authentication
Now, let's examine the other dimension of security, the intruder tools. L0phtCrack 2.0 can crack only captured authentications that contain the standard combination of the LM and NT response. The L0phtCrack Server Message Block (SMB) authentication sniffer, READSMB, captures an authentication to a text file that it feeds to L0phtCrack for cracking. (Lm-fix disables LM authentication, but READSMB can still capture the NT response.) L0phtCrack will process READSMB's output file of the LM and NT responses and ignore the NT response. L0phtCrack cracks the weaker LM response by using dictionary attacks, which crack poor-quality passwords in mere seconds. L0phtCrack subjects an LM response that isn't in the dictionary to a brute force algorithm that takes days to crack.
L0phtCrack 2.5 has more flexible cracking options. Screen 3 shows a new hybrid crack that uses brute force in combination with a dictionary. This hybrid crack calculates how a user might used a common word (with some additional numbers or symbols) to meet the password policies that the Microsoft Windows NT Server 4.0 Resource Kit PassProp utility defines. Although this method takes longer than a dictionary attack, attacks using this method decipher passwords such as Apple1 or 2Blue3 much faster than brute force takes. In addition, intruders can easily change the character set for brute force attacks to control crack time or find higher-quality passwords. But the most significant enhancement to L0phtCrack lets an intruder run dictionary attacks on the NT response only. A dictionary crack on the NT response takes longer than an LM response crack takes, but takes only a matter of hours.
Although lm-fix didn't defeat all possible attacks, it defeated typical attacks from intruders using available tools. Microsoft has since enhanced the NTLM protocol, and L0pht Heavy Industries has since enhanced L0phtCrack. Next, I examine how these mutual enemies presently stack up against each other.
LMCompatibilityLevel Protection
The LMCompatibilityLevel Registry value controls what logon responses the clients send to the server and what responses the servers accept. LMCompatibilityLevel is in the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSetControl\ Lsa key, as Screen 4 shows. In SP4 or later, the NT response has two possible versions—NTLM and NTLMv2—and the LM response has two possible versions—LM and LMv2. The later versions are harder to crack. You can set LMCompatibilityLevel, of type REG_DWORD, between the levels 0 and 5, with level 5 offering the highest security and lowest backward compatibility. To provide the highest security, you need to prevent transmission of the LM response, which is vulnerable to shrink-wrapped intruder tools. Table 1 lists a brief description of the security function for each value of LMCompatibilityLevel.
Level 0. Because LMCompatibilityLevel 0 sends both the NT and the LM responses, this level is highly vulnerable to both dictionary and brute force attacks on the LM response. Level 0 is also the default value for LMCompatibilityLevel when you install SP4 or later. Therefore, merely installing SP4 or later doesn't improve security.
Level 1. Level 1 uses NTLMv2 session security if negotiated between the client and server. By its description, level 1 seems to automatically negotiate the highest level of authentication possible (i.e., NTLMv2). But level 1 falls back to LM authentication where necessary and doesn't improve authentication security.
To understand level 1, let's look at SP3 and the lm-fix hotfix. Fixing the vulnerabilities that LM authentication caused was more complicated than Microsoft estimated. This complication was because of pass-through authentication and the backward compatibility requirement with downlevel systems that support LM authentication only but can function as clients or servers to NT systems. If you use L0phtCrack 2.5 to capture authentications from an SP3 system with lm-fix loaded and LMCompatibilityLevel set to level 2, the SMB Packet Capture Output will display the normal NT response and will display zeros for the LM response to confirm that this configuration disables LM authentication. However, this solution was overly simplified because the negotiation of NT authentication between the client and server, which level 1 specifies, isn't really possible.
With SP3 and lm-fix, level 1 was broken in two ways. First, level 1 confused session security and authentication. Authentication can't safely use the LM response to negotiate, because the server doesn't make the decision—the domain controller does. The client and the server can negotiate session security only, because authentication requires that the client and the client's domain controller agree about what authentication to use. Second, session security negotiation is subject to man-in-the-middle attacks and thus doesn't provide real protection.
Microsoft considered disabling level 1 in SP4 but didn't. Microsoft discovered that if a user has an NT client and a Windows 3.x client and the user changes his or her password from the Windows 3.x machine, the NTLM hash isn't in the SAM. In this case, a user authentication from NT will fail at level 2. Therefore, Microsoft included level 1 in SP4 to let customers have the advantage of NTLMv2 session security.
According to documentation, level 1 still sends the LM response and the NTLMv2 response in place of NTLM when possible. Ordinarily, L0phtCrack 2.5 cracks the all-uppercase LM passwords, then quickly works through all possible case variations to determine the case-sensitive NT versions of the password. In theory, L0phtCrack would need to crack only the LM responses, leaving the intruder to figure out the case-sensitive version, because L0phtCrack can't crack NTLMv2 responses. However, with level 1, I fully cracked captured authentications to the case-sensitive level, which means the client sent the NTLM response instead of the NTLMv2 response and suggests some possible bugs with level 1 negotiation. The bottom line is that level 1 is vulnerable to both dictionary and brute force attacks on the LM response.
Level 2. Level 2 specifies NTLM authentication only. When using L0phtCrack's SMB Packet Capture mode against a level 2 system, intruders might expect to see only the NT Hash column filled with data and the LanMan Hash column filled with zeros. As Screen 2, line 3 shows, both response columns have the same value. With level 2, NT fills both the NT Hash and LanMan Hash columns with the NTLM response. This response pair lets SP4 or later level 2 clients connect to downlevel servers using a domain account without sending the LM response. Because the downlevel servers understand only LM authentication, they ignore the NT response and forward the LM response to the domain controller. If the domain controller has SP4 or later, the authentication will work.
Level 2 defeats L0phtCrack's default mode, which concentrates on the LM response. In this case, L0phtCrack uses the LM crack algorithm on an NT response. An intruder can still configure L0phtCrack to perform a dictionary attack on the NT response to find the password. But passwords that require the dictionary/brute hybrid attack will probably take too long to crack to be of interest to an intruder, and passwords that require brute force might take years to crack, even with many systems sharing the crack workload. So, to eliminate LM vulnerabilities, set your workstations to level 2, but remember that with level 2, low-quality passwords are still susceptible to cracking.
Level 3. Level 3 specifies NTLMv2 authentication only. When an intruder sniffs a level 3 authentication, the NT Hash column fills with the NTLMv2 response and the LanMan Hash column fills with a LMv2 response.
Microsoft had planned to substitute the LM response with the NTLMv2 response to provide pass-through authentication to downlevel servers, but NTLMv2 responses are longer than 24 bytes. The NTLM authentication protocol specifies that response slots have variable length, therefore downlevel servers should forward the whole response to the domain controller. However, downlevel OSs aren't protocol-compliant and forward only the first 24 bytes of the LM response to the domain controller. So, Microsoft created a 24-byte LMv2 response, which level 3 clients send as an LM response and L0phtCrack records in the LanMan Hash column.
LMv2 is more secure than NTLM, because it computes a 128-bit (rather than NTLM's 56-bit) secret from the password. L0phtCrack 2.5 can't crack responses that have the NTLMv2 and LMv2 combination.
Until L0pht Heavy Industries updates L0phtCrack to crack NTLMv2 responses, level 3 would be very secure, if it worked. In my repeated experiments, level 3 clients consistently failed to log on to SP4 or later servers, regardless of the server's LMCompatibilityLevel. Using an account on the domain controller, I issued the Net Use command to connect to a shared folder on a domain controller. In my testing, level 3 didn't work at all. At press time, Microsoft hadn't responded to the level 3 problem.
Level 4. Level 4 documentation is somewhat ambiguous. In some places, the documentation says level 4 refuses LM authentication, which could mean that level 4 will refuse any client that sends the LM response. Elsewhere, the documentation says level 4 refuses downlevel clients. On testing level 4, I verified that it applies to only downlevel clients. For example, on my server, level 4 refused a connection from my DOS workstation running LAN Manager client software, but level 4 didn't refuse connections from NT clients, even when they sent the LM response. Of course, level 4 doesn't apply to downlevel clients connecting to a non-domain-controller server with a domain account, because the server simply forwards the credentials to the domain controller.
Level 4 specifies that servers refuse connections from downlevel clients using a local account on that server and that domain controllers refuse any connection from downlevel clients. Therefore, you can use level 4 to make sure that you have no downlevel clients sending the vulnerable LM response. However, you can't use level 4 to prevent connections from NT clients that are still sending the LM response. For NT systems, you must prevent the transmission of the LM response at the workstation level by using SP4 or later and LMCompatibilityLevel 2 or above.
Level 5. Level 5 specifies the refusal of clients that send anything but NTLMv2 responses. (Level 5 observes the same exception as level 4 for pass-through authentication to non-domain-controller servers.) You could use level 5 to enforce the highest security and make sure that all clients are NTLMv2-compliant, but level 5 unfortunately has some bugs. In my testing, level 5 servers refused all connections, including properly configured NTLMv2 clients. Microsoft has acknowledged this serious bug, but hadn't released a fix as of press time. SP5 didn't address this problem.
Balancing Security and Compatibility
Of course, life is much simpler and safer if all workstations and servers are NT and SP4 or later. With legacy applications that require downlevel OSs, you need to consider the time needed to apply service packs and the possibility of introducing stability problems. You will want to know exactly which systems require updates in each scenario. You can save a lot of time by using System Policy Editor (SPE) to update the Registry and using the resource kit's Autoexnt utility to apply service packs. For information about using the resource kit's Autoexnt utility, see "Managing Service Packs and Hotfixes," http://www.winntmag.com, InstaNT document number 4996.
Whenever possible, you need to prevent your clients from transmitting the LM response. So, until Microsoft resolves the problems with level 3, I recommend implementing level 2. To avoid having workstations that can't connect to your servers, you need to follow these three steps to update your systems in the correct order.
Install SP4 or later on all domain controllers. (This rule doesn't apply to resource domain controllers because they forward responses to the domain controller in which the account resides.) If your current account is on an SP4 or later domain controller, you can use a level 2 or 3 workstation to map drives to a pre-SP4 server in a trusted domain in which the trusted domain controllers haven't applied SP4 or later.
Identify any downlevel systems such as file or print servers. You need to identify these systems, because level 2 NT workstations can't connect to downlevel computers that use share-level security and non-null passwords. Downlevel systems let you share files by using user-level or share-level security. Share-level security requires downlevel systems to validate the response locally against the share-level password, but on NT clients, the validation will fail because downlevel systems don't understand NTLM responses. If you're using a domain account, user-level security will work because the downlevel system will forward the response to the domain controller. You need to upgrade the downlevel servers to NT or switch to user-level security with domain accounts.
Identify any pre-SP4 NT servers using local accounts instead of domain accounts. You'll need to upgrade these servers to SP4 or later because they'll perform authentication locally and won't understand responses from level 2 clients.
A Few Last Words of Advice
I want to close this technical discussion by making sure you know where to go from here for best possible security. Remember the two main risks from sniffed authentication and subsequent cracking—dictionary cracks and brute force attacks. First, intruders will attack the captured response with a dictionary crack that will quickly uncover any poor password. All versions of the NT response are vulnerable to a dictionary attack. LM and NTLM responses are vulnerable to currently available intruder tools. The NTLMv2 response is vulnerable, but no intruder tools are yet available to exploit it. Second, intruders can launch brute force attacks to crack higher-quality passwords. LM responses built from even complex passwords are extremely vulnerable to brute force attacks—to the point of requiring only trivial effort. NTLM responses built from complex passwords are less vulnerable to brute force, but when hardware gets faster, this resistance will change. NTLMv2 provides much stronger protection against brute force attacks. But when L0pht Heavy Industries revises L0phtCrack, NTLMv2 might be vulnerable to dictionary attacks on poor-quality passwords.
A crucial distinction exists between threats that are theoretical and threats from currently available tools. Corporations suffer the most losses from intruders who don't know how to write a tool such as L0phtCrack but can definitely use one.
The moral of the security story is threefold. First, require long high-quality passwords from your users. As a start, I recommend that users create password phrases in which the first letter of each word makes up the password, then intersperse numbers and symbols. You need to use PassProp and password-notification packages (e.g., passfilt.dll) to enforce stronger password requirements. Second, use the strongest possible version of NT authentication. Try to eliminate LM authentication altogether, because intruder tools can easily crack high-quality passwords when using LM responses. To eliminate LM authentication, you'll need to upgrade your NT systems to SP4 or later and use LMCompatibilityLevel 2. When Microsoft makes fixes available for LMCompatibilityLevel 3 and 5, move your workstations to level 3 and your servers and domain controllers to level 5. As for the downlevel clients, the sooner you replace them, the better your security and total cost of ownership (TCO) will be. NTLM authentication will always be subject to sniffing and cracking, especially with low-quality passwords.
Finally, look forward to the future—Windows 2000 (Win2K) replaces NTLM with Kerberos and extends the Kerberos standard to support certificates stored on smart cards. Let's hope these enhancements will provide permanent protection for network authentication.
