Sorry about the detour, I got a little bit distracted with the Google press release and then the OpenID stuff.
So, we left off the Windows Authentication discussion by concluding that LM authentication is really unsecure is only kept around for backwards compatibility (old crappy applications or old Windows machines). In continuing this discussion, we will now talk about NTLM and NTLMv2. For those of you that may not be familiar with NTLM, let me give you a brief run down.
The acronym NTLM stands for NT LAN Manager which is a challenge and response authentication protocol that was developed by Microsoft. As you may have guessed, NTLM was LM’s replacement (do not confuse the two). The protocol itself, is implemented by the NTLM Security Support Provider (“NTLMSSP”), and is primary used for authentication and negotiation of secure DCE/RPC connections. However, NTLM may also be used for accessing a number of other services such as web servers, SMTP, POP3, IMAP, CIFS/SMB, Telnet…
With NTLM, there are two versions of the protocol. These versions are named NTLMv1 and NTLMv2. The older version, NTLMv1 (hey the version numbers are in order) was introduced to bring about three major changes to the underlying LM protocol:
- 1) The LM hash was increased to 14 bytes
- 2) Upper and lower case characters were now supported
- 3) Support for an MD4 hash was introduced (NT hash)
While these are all very wonderful improvements NTLMv1 did not solve all of LM’s security flaws. After all, NTLMv1 still supported the LM hash and operated essentially the same way as the LAN Manager authentication protocol (for backward compatibility) which was originally developed in the mid-1980s.
To address some of the security concerns with NTLM, Microsoft introduced NTLMv2 in Windows NT 4.0 SP4. With this new iteration came the following major changes:
- 1) The LM hash has was increased to 128 bytes
- 2) MD5 was used for the NT hash
In addition, some enchantments were also made to how the underlying protocol handled authentication requests. For example, NTLMv2 supports 128-bit keys, uses different keys for signing and sealing activities, and uses an HMAC-MD5 to hash parts of the response buffer. Needless to say, despite these improvements, NTLMv2 still poses a number of security challenges in relation to replay attacks and the fact that it is still based an extremely old protocol (LM).
So… given the information that I just dumped into this posting, NTLMv2 is by default more secure then LM and NTLMv1. The only problem, as I have pointed through-out this posting is that NTLMv2 still supports LM hashes. In addition, you need to make some OS tweaks to force usage of NTLMv2 and aspects of its more secure implementation. With this in mind, use the steps I outlined in my previous posting to prevent the usage of LM hashes. In addition, you will want to understand how the LMCompatibilityLevel registry value can be used to force usage of NTLMv2. Or, if you are feeling randy, you can control this value via GPO. The setting that you will want to consider is: “Clients use only NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controller refuses LM and NTLM authentication responses, but it accepts NTLMv2.”
Additionally, you will want to force the minimum session security for the NTLM SSP. You can accomplish this task by either again hacking the registry (the value you are interested in is named NtlmMinClientSec). Or, you can again use GPO. In either case, you can use the setting to force negotiation of message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security.
At this point in the series we have now knocked off LM and NTLM from our list decent authentication protocols. In addition, we have our Windows environment configured such that only NTLMv2 (when appropriate) is used and only with the securest of the session security settings. Granted we have now also broken all of those old Windows NT 3.1 machines still left on the network. But, our attack surface has been greatly reduced and we have given the accounting department reasons to look into upgrading their “un-supported” software.
Stick around, in my next posting in this series, I will review Kerberos and we will discover the secrets of the TGT.
