Microsoft NTLM қауіпсіздік протоколдары

Suite of Microsoft security protocols for authentication, integrity, and confidentiality
In a Windows network, NT (New Technology) LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system which is governed by Group Policy settings, for which different versions of Windows have different default settings. NTLM passwords are considered weak because they can be brute forced very easily with modern hardware. First, the client establishes a network path to the server and sends a NEGOTIATE MESSAGE advertising its capabilities. Next, the server responds with CHALLENGE MESSAGE which is used to establish the identity of the client. Finally, the client responds to the challenge with an AUTHENTICATE MESSAGE. The NTLM protocol uses one or both of two hashed password values, both of which are also stored on the server (or domain controller), and which through a lack of salting are password equivalent, meaning that if you grab the hash value from the server, you can authenticate without knowing the actual password. The two are the LM hash (a DES based function applied to the first 14 characters of the password converted to the traditional 8 bit PC charset for the language), and the NT hash (MD4 of the little endian UTF 16 Unicode password). Both hash values are 16 bytes (128 bits) each. The NTLM protocol also uses one of two one way functions, depending on the NTLM version; NT LanMan and NTLM version 1 use the DES based LanMan one way function (LMOWF), while NTLMv2 uses the NT MD4 based one way function (NTOWF). (and natively supported in Windows 2000), is a challenge response authentication protocol. It is intended as a cryptographically strengthened replacement for NTLMv1, enhancing NTLM security by hardening the protocol against many spoofing attacks and adding the ability for a server to authenticate to the client. NTLMv2 sends two responses to an 8 byte server challenge. Each response contains a 16 byte HMAC MD5 hash of the server challenge, a fully/partially randomly generated client challenge, and an HMAC MD5 hash of the user's password and other identifying information. The two responses differ in the format of the client challenge. The shorter response uses an 8 byte random value for this challenge. In order to verify the response, the server must receive as part of the response the client challenge. For this shorter response, the 8 byte client challenge appended to the 16 byte response makes a 24 byte package which is consistent with the 24 byte response format of the previous NTLMv1 protocol. In certain non official documentation (e. g. DCE/RPC Over SMB, Leighton) this response is termed LMv2. The second response sent by NTLMv2 uses a variable length client challenge which includes (1) the current time in NT Time format, (2) an 8 byte random value (CC2 in the box below), (3) the domain name and (4) some standard format stuff. The response must include a copy of this client challenge, and is therefore variable length. In non official documentation, this response is termed NTv2. Both LMv2 and NTv2 hash the client and server challenge with the NT hash of the user's password and other identifying information. The exact formula is to begin with the NT hash, which is stored in the SAM or AD, and continue to hash in, using HMAC MD5, the username and domain name. In the box below, X stands for the fixed contents of a formatting field. SC = 8 byte server challenge, random
CC = 8 byte client challenge, random
CC* = (X, time, CC2, domain name)
v2 Hash = HMAC MD5(NT Hash, user name, domain name)
LMv2 = HMAC MD5(v2 Hash, SC, CC)
NTv2 = HMAC MD5(v2 Hash, SC, CC*)
response = LMv2 | CC | NTv2 | CC*

After it has been decided either by the application developer or by the Negotiate SSP that the NTLM SSP be used for authentication, Group Policy dictates the ability to use each of the protocols that the NTLM SSP implements. There are five authentication levels. Send LM & NTLM responses: Clients use LM and NTLM authentication, and never use NTLMv2 session security; DCs accept LM, NTLM, and NTLMv2 authentication. Send LM & NTLM use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication. Send NTLM response only: Clients use NTLM authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM (accept only NTLM and NTLMv2 authentication). Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM and NTLM (accept only NTLMv2 authentication). DC would mean Domain Controller, but use of that term is confusing. Any computer acting as server and authenticating a user fulfills the role of DC in this context, for example a Windows computer with a local account such as Administrator when that account is used during a network logon. Prior to Windows NT 4.0 Service Pack 4, the SSP would negotiate NTLMv1 and fall back to LM if the other machine did not support it. Starting with Windows NT 4.0 Service Pack 4, the SSP would negotiate NTLMv2 Session whenever both client and server would support it. Up to and including Windows XP, this used either 40 or 56 bit encryption on non U. S. computers, since the United States had severe restrictions on the export of encryption technology at the time. Starting with Windows XP SP3, 128 bit encryption could be added by installing an update and on Windows 7, 128 bit encryption would be the default. In Windows Vista and above, LM has been disabled for inbound authentication. Windows NT based operating systems up through and including Windows Server 2003 store two password hashes, the LAN Manager (LM) hash and the Windows NT hash. Starting in Windows Vista, the capability to store both is there, but one is turned off by default. This means that LM authentication no longer works if the computer running Windows Vista acts as the server. Prior versions of Windows (back as far as Windows NT 4.0 Service Pack 4) could be configured to behave this way, but it was not the default.

NTLM remains vulnerable to the pass the hash attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08 068. For example, Metasploit can be used in many cases to obtain credentials from one machine which can be used to gain control of another machine. The Squirtle toolkit can be used to leverage web site cross site scripting attacks into attacks on nearby assets via NTLM. In February 2010, Amplia Security discovered several flaws in the Windows implementation of the NTLM authentication mechanism which broke the security of the protocol allowing attackers to gain read/write access to files and remote code execution. One of the attacks presented included the ability to predict pseudo random numbers and challenges/responses generated by the protocol. These flaws had been present in all versions of Windows for 17 years. The security advisory explaining these issues included fully working proof of concept exploits. All these flaws were fixed by MS10 012. In 2012, it was demonstrated that every possible 8 character NTLM password hash permutation can be cracked in under 6 hours. In 2019, this time was reduced to roughly 2.5 hours by using more modern hardware. Also, Rainbow tables are available for eight and nine character NTLM passwords. Shorter passwords can be recovered by brute force methods. In 2019, EvilMog published a tool called the ntlmv1 multitool to format NTLMv1 challenge responses in a hashcat compatible cracking format. With hashcat and sufficient GPU power the NTLM hash can be derived using a known plaintext attack by cracking the DES keys with hashcat mode 14000 as demonstrated by atom on the hashcat forums. Note that the password equivalent hashes used in pass the hash attacks and password cracking must first be "stolen" (such as by compromising a system with permissions sufficient to access hashes). Also, these hashes are not the same as the NTLMSSP AUTH "hash" transmitted over the network during a conventional NTLM authentication.

NTLM implementations for Linux include Cntlm and winbind (part of Samba) allow Linux applications to use NTLM proxies. FreeBSD also supports storing passwords via Crypt (C) in the insecure NT Hash form.