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.
Previous
