sign in sign up
<<
Home , LAN Manager, Windows Vista

The Most Misunderstood Windows Security Setting of All Time Jesper Johansson

Almost everyone who runs a network on Windows has heard of LetMeIn1 = LETMEIN + 1****** NTLM version 2 (NTLMv2) and the Key Key LMCompatibilityLevel setting that governs it. The setting first became available in Windows aad3b435b51404ee Constant NT 4.0 4 (SP4), and has been in DES DES every version of Windows based on Windows Encryption Encryption NT since then. LMCompatibilityLevel has been recommended in every security guide for Windows since 1998. LM Hash A few years ago I thought I really knew Concatenate how LMCompatibilityLevel worked. I was wrong. Then for a couple of years I thought Figure 1 LM Hash Generation I knew how it worked again. This has hap- pened a few times, and recently I found out characters and up to 256 char- operation reduces the strength of the pass- that I still didn’t completely understand it. acters long. word by many orders of magnitude. This prompted me to finally go back to the The LM hash, originally invented for use Windows uses the LM OWF for the LM code, tear through it, and figure out what re- in LAN Manager over 20 years ago, is not protocol and the NT OWF ally was going on. This article is about what I actually a hash at all (see Figure 1). A hash for everything else. One common miscon- found. Anyone who runs Windows probably is a mathematical function used to sum- ception is that the system stores a specific should understand this setting and how it marise or probabilistically identify data. NTLMv2 OWF. There is not even an NTLM impacts network security and stability. LM instead uses a cryptographic one-way OWF for the NTLM protocol. The NT OWF function (OWF). Instead of encrypting the is used for all other Windows authentica- Background with some other key, the password tion protocols in one way or another. The Windows NT-based operating systems itself is the key. This is why you will some- two OWFs are used in the authentication up through and including times see the LM hash referred to as the LM sequence as shown in Figure 2. 2003 store two password hashes, the LAN OWF. Conversely, the NT hash is typically Both the LM and NTLM protocols operate Manager (LM) hash and the Windows NT referred to as the NT OWF internally. essentially the same way; the only difference hash. Starting in , the capa- The algorithm introduces several weak- is the password hash. The actual challenge- bility to store both is there, but one is turned nesses that attackers can exploit. First, all response computation is fairly simple. The off by default. lowercase characters are set to uppercase, client requests authentication and the au- The NT hash is a straight MD4 hash of the reducing the number of possible charac- thentication server responds with an 8-byte plaintext password. It supports all ters. Second, it splits a long, strong, pass- challenge. The challenge is just a piece of word into two seven-character chunks. random data. The client encrypts the chal- Jesper Johansson, a senior security strategist in the Se- Length has been shown to be the most im- lenge using the OWF as the key and returns curity Technology Unit and contributing editor for TechNet Magazine, focuses on how customers should best deploy Microsoft products portant factor in password strength by far the result as the response to the server. The more securely. He has a PhD in IS and has delivered speeches on (see microsoft.com/technet/community/columns/secmg- LM and NTLM responses are each always security at conferences all over the world. mt/sm1005.mspx for more on this topic). This 24 bytes long. The server has the NT OWF Prerelease info in this column is subject to change. TechNet Magazine October 2006 73 Network (www.protectyourwindowsnetwork.com), which covers the topic in much more detail. Client 1. Hey, I’d like to authenticate Server How NTLMv2 Works 2. OK, here is a challenge The NTLMv2 response is very different. 3. LM response = First, the client concatenates the user name DES(LM OWF[0-6], Challenge) + and the logon domain name and computes DES(LM OWF[7-13], Challenge) + DES((LM OWF[14-15]+5*NULL), an HMAC-MD5 Challenge) code of those using the NT OWF as a key. 4. NTLM Response = The result of this keyed hash is sometimes DES(NT OWF[0-6], Challenge) + referred to as the NTLMv2 OWF. The log- DES(NT OWF[7-13], Challenge) + DES((NT OWF[14-15]+5*NULL), on domain name is the account the client Challenge) is attempting to log on to. In the case where 5. Response = (LM Response, a workstation is trying to contact a system NTLM Response) that is not in the client’s domain, this would be the server name. Figure 2 LM and NTLM Response Computation The client then generates its own 8-byte challenge, which it puts into a blob that also and usually the LM OWF as well. It starts L0phtCrack password cracker from L0pht contains a timestamp, information on the by computing the NTLM response using Heavy Industries, later purchased by @Stake target the client is attempting to connect the same algorithm the client used, and and finally by Symantec, included a cracker to, and some other data. This blob is then then compares that to the client result. If against a captured LM authentication se- concatenated with the server challenge and the two match, they used the correct pass- quence, Microsoft implemented the new another HMAC-MD5 message authentica- word hash and—by an extension of logic NTLMv2 to defeat tion code is computed on this combined that is not always correct—had the correct L0phtCrack. (For a synopsis of the protocol challenge using the NTLMv2 OWF as the password, a successful logon results. If the and the attack that caused it to be created, key. The result of that computation is con- results do not match, the server computes see this Windows IT Pro article: windowsitpro.com/ catenated with the blob and returned as the LM response and checks if that matches Articles/Index.cfm?ArticleID=7072. Keep in mind, the NTLMv2 response buffer. The client what the client sent. If that fails too, the cli- however, that this article was published in also computes a response based only on the ent is denied access due to a bad username 1999 and is now fairly dated and not entirely NTLMv2 OWF, the server challenge, and the or password error. accurate in some respects.) client challenge. This response is called the NTLMv2 was developed in response to at- NTLMv2 is turned on using the LMCom­ LM 2 Response and is returned in the LM tacks against the LM authentication protocol. patibilityLevel switch (known as some vari- response field along with the client chal- The LM protocol, as the name implies, was ant on “LAN Manager authentication level” lenge, as shown in Figure 5. originally used in the old LAN Manager net- in ). LMCompatibilityLevel The entire NTLMv2 response buffer is work in the mid-1980s. It takes six different values, from 0 to 5. The not documented publicly, but many sourc- was developed for the security requirements levels are shown in Figures 3 and 4. es have inferred a lot about it. Essentially, of the day, which included mostly floppy- Admittedly, this is a brief introduction to it contains version information, room for based viruses, and hence was no match for Windows and passwords. Interested readers flags in a future implementation, room a late 90s-style cracking attack. When the should see chapter 11 in Protect Your Windows for a message from the client to the server

Figure 3 Client-Side LMCompatibilityLevel Impact

Level Group Policy Name Sends Accepts Prohibits Sending 0 Send LM and NTLM LM, NTLM LM, NTLM, NTLMv2 Responses NTLMv2 Session Security is negotiated NTLMv2 Session Security (on below SRP1, Windows NT 4.0 and ) 1 Send LM and NTLM— LM, NTLM LM, NTLM, NTLMv2 use NTLMv2 session NTLMv2 Session Security is negotiated NTLMv2 security if negotiated 2 Send NTLM response NTLM LM, NTLM, LM and NTLMv2 only NTLMv2 Session Security is negotiated NTLMv2 3 Send NTLMv2 NTLMv2 LM, NTLM, LM and NTLM response only Session Security is always used NTLMv2

74 To get your FREE copy of TechNet Magazine subscribe at: www.microsoft.com/uk/technetmagazine Once again, I thought I knew exactly how Figure 4 Server-Side LMCompatibilityLevel Impact it worked, and I wrote another article on it. Level Group Policy Name Sends Accepts Prohibits Shortly after that, Seki Hidenobu wrote to Sending me, prodding about something he called 4 Send NTLMv2 response NTLMv2, Session NTLM, LM “NTLM2 Session Response”, a term he picked only/refuse LM security NTLMv2 up from Eric Glass. In fact, not only does 5 Send NTLMv2 response NTLMv2, Session NTLMv2 LM and the Ethereal network sniffer filters identify only/refuse LM and NTLM security NTLM NTLM2 Session Response, it has even been documented as part of the (the UNIX (which is not used today), the timestamp, you set LMCompatibilityLevel to 1, it does implementation of SMB) documentation. In the client challenge, and some information not actually send NTLMv2 authentication. addition, Christopher R. Hertel’s book on the about the server and share name the client Then another epiphany hit me. The docu- Common Internet (CIFS—the is connecting to. mentation, which says that “DCs will accept” standardised version of the Microsoft Server As noted earlier, when NTLMv2 is used, and “clients will send” is really misleading. Message Block, or SMB, protocol) contains the LM response changes as well. This is The simpler way to think about the settings is a very technical and detailed description of done for compatibility with servers that all the protocols involved and discusses the are domain members but do not under- I conveniently NTLM2 Session Response. More informa- stand NTLMv2. The problem is that the tion on this book is at www.ubiqx.org/cifs. These NTLMv2 response is variable in length, in- pushed aside the documents were largely developed while add- cluding items such as the server name, the feeling that I still ing NTLMv2 support to Samba. Luke K. tag">C. share name, and so on. Older domain-joined Leighton, who wrote most of the NTLMv2 servers, such as Windows NT 4.0 prior to did not understand code for Samba, also wrote a book on the SP4 and Windows 9x cannot pass through NTLMv2 Session protocols, DCE/RPC over SMB: Samba and a variable-length response to the domain Windows NT Domain Internals (SAMS, 1999). controller; they assume that both the LM Security. That book even includes for an and NTLM responses are exactly 24 bytes. implementation of NTLMv2. By luck or very smart design, an HMAC- that levels 0-3 affect the when act- MD5 computation yields a 128-bit value ing as a client, while levels 4 and 5 affect the NTLMv2 Session Security which, when combined with the 8-byte client machine when acting as the authentication Hidenobu did not know exactly what the challenge, gives us 192 bits or 24 bytes—ex- server. It is not just domain controllers that NTLM2 Session Response was for and why actly the same as the three Data Encryption authenticate users. All systems can authenti- it appeared but as he pointed out, it can be Standard (DES) computations used in the cate users against their own SAM database, cracked. Basically, when it is used, you do LM response. The older machines can thus so the settings really affect all of them. not pass the LM response. Instead, a client pass the LMv2 response through to the do- main controller without needing to under- stand the exact meaning of the bits within Client Server it. The domain controller will do the same 1. Hey, I’d like to authenticate computation it always does, checking first 2. OK, here is a challenge if the response is an NTLMv2 response, and if that fails falling back to LMv2, and then 3. NTLMv2OWF = HMACMD5(NTOWF, to the older protocols. Username, LogonDomainName) Until recently, I thought this was all there 4. NTLMv2Response = was to LMCompatibilityLevel. I conveniently HMAC-MD5(NTLMv2OWF, pushed aside the feeling that I still did not ServerChallenge, ResponseType, ..., understand the thing referred to as NTLMv2 TimeStamp, ClientChallenge, ...) Session Security. 5. LMv2Response = HMAC-MD5(NTLMv2OWF, Years of Confusion ServerChallenge + As did Randy Franklin Smith in the article ClientChallenge) mentioned earlier, I believed for years that at 6. Response= (client challenge + level 1, the system was supposed to send the LMv2Response, NTLMv2 LM response (which is correct) and would Response Buffer) negotiate and send the NTLMv2 response if it were possible. This is incorrect. When Figure 5 LMv2 and NTLMv2 Response Computation TechNet Magazine October 2006 75 not used during the actual authentication Client 1. Hey, I’d like to authenticate Server sequence, but when an application requests security by calling the EncryptMessage or 2. OK, here is a challenge SignMessage . In other words, you can think of NTLMv2 3. Generate 8-byte client challenge Session Security as having two components: a stronger response computation and a bet- 4. Blob = ter session key generation algorithm. The re- HMAC-MD5(ClientChallenge, ServerChallenge) sponse computation, however, can be either the mysterious NTLM2 Session Response or 5. Modified NTLM Response = DES(NT OWF[0-6], blob) + a real NTLMv2 response. DES(NT OWF[7-13], blob) + NTLMv2 Session Security can be forced DES((NT OWF[14-15]+5*NULL), blob) by setting the LMCompatibilityLevel setting, 6. Response = Client Challenge, but it is also negotiated between the client Modified NTLM Response and the server. Starting with Windows 2000 Security Rollup Pack 1 (SRP1) all systems will Figure 6 Response Computation for LMCompatibilityLevel 1 or 2 attempt to use NTLMv2 Session Security if both sides agree. If either side disagrees they challenge is created and mixed with the means that, as Glass pointed out, it is seen will fall back to the old protocols if they are server challenge using HMAC-MD5. Then when you use NTLMv2 Session Security. It configured to allow that. the NTLM response to this combined chal- was created to make certain man-in-the- lenge is computed the normal way, as shown middle attacks more difficult by introducing LMCompatibilityLevel and in Figure 2, by using three DES encryptions a client-side challenge, while still retaining Security of the challenge with pieces of the nonce, the ability for downlevel clients to pass the As mentioned earlier, starting with and returned to the server in the NTLM re- authentication through to an upgraded do- Windows 2000 SRP1, including Windows sponse field. The client challenge is returned main controller. This new response does not 2000 SP3, all versions of Windows XP and all in the now unused LM response field. This really even have a name, and has never been versions of , NTLMv2 modified NTLM response can be cracked documented by Microsoft. In the source Session Security is always negotiated. using a modified precomputed hash attack code the term “NTLM2” sometimes shows Therefore, there is no longer any functional even though there is now a client challenge up, contrasted with “NTLM3”, which is re- difference between LMCompatibilityLevel involved. Seki exploited the fact that only two bytes of the challenge are used in the What the Samba documents call the “NTLM2 third component of the response. Once he identifies which bytes those are, he can use Session Response” is actually a slightly them as an index into a lookup table to de- modified version of the NTLM response. termine all the passwords that could have possibly generated an OWF with those two ally NTLM version 2. It is possible that the 0 and 1. They generate exactly the same re- bytes at the end. use of the term NTLM2 Session Response sults on all supported platforms. Eric Glass, who did not have the luxury originated from someone who was looking The difference between LMCompati­ or the curse (depending on how you look at debug symbols and saw that term. bilityLevel set to 0 or 1 and setting it to 2 is at it) of Windows source code access, stat- NTLMv2 Session Security has been an- that with level 2 the client refuses to send ed that the “NTLM2 Session Response can other enigma. In fact, “NTLMv2 Session the LM response. This is why level 2 is the be used in conjunction with NTLM2[sic] Security” is really a misnomer. It really should default setting on Windows Server 2003. Session Security….” This is, in fact, almost be referred to as “NTLMv2-style session It also means that Windows Server 2003 exactly the correct description. To produce key computation”, although one can eas- cannot be a client to a Windows 9x system an answer for Hidenobu I ended up having ily understand why that term never caught unless it passes the authentication through to go back to the source code. It turns out on. NTLMv2 Session Security is related to to a domain controller. When acting as the that what the Samba documents call the how session keys are computed. When us- authentication server, however, Windows “NTLM2 Session Response” is actually a ing the original NTLM protocol, the session Server 2003 accepts LM responses and au- slightly modified version of the NTLM re- key is based on the user’s NT hash (the NT thenticates against the LM hashes stored sponse, shown in Figure 6. OWF). When NTLMv2 Session Security is locally or in . This modified response is used when the used, the session key is based on not only This meant I had to modify my ta- client knows it is talking to an uplevel serv- the NT OWF but also on the client and bles showing how the various levels of er that can handle this new response. This server challenges. Those session keys are LMCompatibilityLevel work. Figure 3 shows 76 To get your FREE copy of TechNet Magazine subscribe at: www.microsoft.com/uk/technetmagazine the settings that affect how the system acts The NtlmMinClientSec and NtlmMinServerSec settings, which are known as SSP NTLM the Hardening as a client. Figure 4 shows how the settings some variant of “Minimum session security for NTLM SSP based (including se- affect the system when acting as an authen- cure RPC) clients” in Group Policy, govern which behaviours are allowed for ap- tication server. plications using the NTLM Security Support Provider (SSP). The SSP Interface Levels 0 and 1 are identical on systems with (SSPI) is used by applications that need authentication services. Windows 2000 SRP1 or higher. The Security The NtlmMinClientSec and NtlmMinServerSec settings do not modify how Rollup Pack is included in Windows 2000 the authentication sequence works. Rather, they are used to require certain SP3 and, of course, the same functionality behaviours in applications that use the SSPI. Each setting contains a bitmask with respect to NTLMv2 Session Security that can be used to require some combination of up to four different types of is turned on by default in Windows XP and behaviours, shown in Figure A. Windows Server 2003. The easiest way to differentiate between the NTLM SSP settings and In terms of actual security impact, ne- LMCompatibilityLevel setting is by just considering the items they affect. The gotiating NTLMv2 Session Security ranges SSPI settings govern the behaviour of applications that use authentication, from significant to minimal, depending on while LMCompatibilityLevel governs which authentication protocols the oper- the environment. Theoretically, NTLMv2 ating system can use. Session Security can be used with any pro- tocol. But used with NTLM version 1, it also improves the challenge response computa- Figure A SSPI Behaviours tion by including the client-side challenge, Behaviour Description similar to how NTLMv2 itself works. This Message integrity Applications that do not digitally sign their traffic are makes a precomputed hash attack against blocked. captured challenge-response pairs more dif- Message confidentiality Applications that do not encrypt their traffic are blocked. ficult, but certainly not impossible. More NTLMv2 Session Applications must request NTLMv2 session keys and use significantly, it makes man-in-the-middle Security them for signing and/or encryption. attacks much more difficult. 128-bit security Applications must use strong , where strong NTLMv2 Session Security is still negotiat- means using 128-bit or stronger keys. ed. Therefore, if the attacker has the ability to act as the server itself or to modify the trans- action in any way, the attacker can down- gether. In Windows Server 2003, NTLM, and network that consists of only Windows 2000 grade the authentication protocols to the sometimes even LM, is used in many cases, SP3 and higher systems, and has no third- older versions, enabling both types of attack such as in clusters. In the next version of the party devices that require LM or NTLM once again. Only if LMCompatibilityLevel operating systems many of these protocols authentication, LMCompatibilityLevel can is set to 3 on the client are these attacks ac- will finally be turned off by default. be safely set to 3 or higher on all systems. tually stopped. Please note that these statements are Problems may occur when level 5 is used based on prerelease versions of the operat- on systems running operating systems prior Recommendations ing systems. It is possible that compatibility to Windows Server 2003 SP1. Routing and Although Windows Vista has not been testing during the beta cycle will force these Remote Access Services will fail if the RRAS released yet, it is worthwhile to point out settings to change. server or the domain controller is running some changes in this operating system re- So what should you do now? In all envi- with LMCompatibilityLevel 5. lated to these protocols. The most impor- ronments you should consider setting the It is also important to consider the error tant change is that the LM protocol can LMCompatibilityLevel as high as possible. messages you get when you have a conflict no longer be used for inbound authenti- The decision needs to take into account in the LMCompatibilityLevel capabilities cation—where Windows Vista is acting as the types of systems used in the environ- of different systems. Effectively, the only the authentication server. Windows Vista ment and how high the of attack is. negotiation in this entire set of protocols is will no longer store the LM hash by default. For instance, inside a datacentre where all NTLMv2 Session Security. Downlevel sys- Acting as a client, Windows Vista also makes communication lines are secured, the threat tems will ignore that flag. Therefore, the only a change to outbound protocols by setting of man-in-the-middle attacks is relatively error message you get if there is a settings LMCompatibilityLevel to 3 by default. In small. In an unsecured or WEP-secured conflict between client and server is that ac- other words, NTLMv2 will finally be the wireless network the risk is significant. cess was denied due to a bad username or default protocol for non-domain authen- Attackers commonly sniff these networks password. Neither side to the transaction has tication. In the next scheduled release of in the hopes of catching the authentication the ability to determine that the issue was the Windows Server platform, code-named sequence and cracking it. due to unsupported authentication proto- “Longhorn Server”, a lot of work has been Generally, the setting should be as high cols. This makes troubleshooting somewhat done to reduce the need for NTLM alto- as the needs of the environment allows. In a challenging. l TechNet Magazine October 2006 77