The risk presented by LM response sniffing can be mitigated in several ways.
One way is to ensure that network security best practices are followed. Keep Windows authentication services within protected networks and ensure that the overall network infrastructure does not allow LM traffic to pass by untrusted nodes. A corollary of this remedy is to ensure that physical network access points (wall jacks and so on) are not available to casual passersby. (Remember that this is made more difficult with the growing prevalence of wireless networking.) In addition, although it’s generally a good idea to use features built into networking equipment or Dynamic Host Configuration Protocol (DHCP) to prevent intruders from registering physical and network-layer addresses without authentication, recognize that sniffing attacks do not require the attacker to obtain a MAC (Media Access Control) or IP address since they operate in promiscuous mode.
In the second case, configure all Windows systems within your environment to disable propagation of the LM hash on the wire. This is done using the Network Security:
LAN Manager Authentication Level setting under Security Policy (Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options node within the Group Policy or Local Security Policy MMC snap-in). This setting allows you to configure Windows 2000 and later to perform LM/NTLM authentication in one of six ways (from least secure to most; adapted from KB article Q239869):
• Level 0 Send LM and NTLM response; never use NTLM 2 session security.
Clients use LM and NTLM authentication and never use NTLM 2 session security; domain controllers accept LM, NTLM, and NTLM 2 authentication.
(This is the default on Windows products through Windows XP.)
• Level 1 Use NTLM 2 session security if negotiated. Clients use LM and NTLM authentication and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.
• Level 2 Send NTLM response only. Clients use only NTLM authentication and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication. (This is the default on Windows.)
• Level 3 Send NTLM 2 response only. Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.
• Level 4 Domain controllers refuse LM responses. Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers refuse LM authentication (that is, they accept NTLM and NTLM 2).
• Level 5 Domain controllers refuse LM and NTLM responses (they accept only NTLM 2). Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers refuse NTLM and LM authentication (they accept only NTLM 2).
By setting LAN Manager Authentication Level to Level 2, Send NTLM Response Only, LM response sniffing tools will not be able to derive a hash from challenge-response authentication. (Settings higher than 2 will also work and are more secure.) Figure 5-10 shows the Windows Security Policy interface in its default setting of the LM Authenti-cation level.
When applying the LM Authentication Level setting on Windows, right-click the top node of the MMC tree in which the setting is displayed and select Reload. This will apply the setting immediately.
What about the newer NTLM and NTLM 2 protocols? The NTLM response is not susceptible to LM response sniffing, since it is not based on concatenated cryptographic material that can be attacked in parallel. For example, L0phtcrack’s SMB Packet Capture will still appear to have captured a Windows client’s LM response even if its LM Authentication Level is set to 2, but once imported into L0phtcrack for cracking, password hashes derived from NTLM-only responses will not crack within a reasonable timeframe.
As we saw earlier, other LM response sniffing tools like ScoopLM exhibit this same behavior.
The reason for this behavior is usually that the authentication method used is a variant of NTLM, called ntlm2 (not the same as NTLMv2). These hashes can be cracked using tools listed in the “References and Further Reading” section. This is not to say that an attacker cannot crack valid NTLM hashes (as we will see in Chapter 7, it is quite possible).
It is interesting to note that NTLM 2 challenge-responses can be sniffed as well and are vulnerable to a similar attacks. Links to publicly available tools, and a description, are available in “References and Further Reading.”
Figure 5-10 The Windows Server 2003 LANMan Authentication Level default setting prevents sending the vulnerable LM response over the wire.
The LAN Manager Authentication Level setting was configured using the HKLM\
System\CurrentControlSet\Control\LSA\LMCompatibilityLevel Registry key under NT 4, where the Level 0–5 designations originated, even though the numbers don’t appear in the Windows Security Policy interface (see KB article Q147706).
Remember that as long as systems in an environment have not been set to Level 2 or higher, that environment is vulnerable, even if all servers have been set to Level 4 or 5. Clients will still send the LM response even if the server doesn’t support it.
One of the biggest issues large organizations faced when deploying the old LMCompatibilityLevel Registry setting was the fact that older Windows clients could not send the NTLM response. This issue was addressed with the Directory Services Client, included on the Windows 2000 CD-ROM under Clients\Win9x\Dsclient.exe.
Once installed, DSClient allows Windows 9x clients to send the NTLM 2 response.
Windows 9x must still be configured to send only the NTLM 2 response by creating an LSA Registry key under HKLM\System\CurrentControlSet\Control and then adding the following registry value:
Value Name: LMCompatibility Data Type: REG_DWORD
Value: 3
Valid Range: 0,3
On Windows 9x clients with DSClient installed, this Registry value should be named LMCompatibility, not LMCompatibilityLevel, which is used for the NT 4 setting.
It’s also important to note that the LAN Manager Authentication Level setting applies to SMB communications. Another Registry key controls the security of Microsoft Remote Procedure Call (MSRPC) and Windows Integrated Authentication over HTTP on both client and server (they must match):
HKLM\System\CurrentControlSet\control\LSA\MSV1_0 Value Name: NtlmMinClientSec or NtlmMinServerSec Data Type: REG_WORD
Value: one of the values below:
0x00000010- Message integrity 0x00000020- Message confidentiality 0x00080000- NTLM 2 session security 0x20000000- 128-bit encryption 0x80000000- 56-bit encryption
Finally, as we’ve noted frequently in this chapter, Windows 2000 and later versions are capable of performing another type of authentication: Kerberos. Because it is a wholly different type of authentication protocol, it is not vulnerable to LM response sniffing.
Unfortunately, clients cannot be forced to use Kerberos by simply setting a Registry value similar to LM Authentication Level, so as long as there are down-level systems in your environment, it is likely that LM/NTLM challenge-response authentication will be used.
In addition, in some scenarios, Kerberos will not be used in a homogeneous Windows 2000 or later environment. For example, if the two machines are in a different Windows 2000 forest, Kerberos will not be used (unless a cross-forest trust is enabled, which is available only in native Windows domains; see Chapter 2). If the two machines are in the same forest, Kerberos may be used—but only if the machines are referenced by their NetBIOS machine names or DNS names; accessing them by IP address will always use LM/NTLM challenge-response. Finally, if an application used within a Windows domain does not support Kerberos or supports only legacy LM/NTLM challenge-response authentication, it will obviously not use Kerberos, and authentication traffic will be vulnerable to LM response sniffing.
Remember also that to set up Kerberos in a Windows 2000 and later environment, you must deploy a domain with Active Directory. Some good tools to use to determine whether Kerberos is being used for specific sessions are the Resource Kit kerbtray utility, a graphical tool, or the command-line klist tool. We’ll discuss Kerberos in more detail in Appendix A.
Remember that earlier in this chapter we demonstrated that Kerberos authentication can be sniffed as well!