November 18, 2004| [3APA3A] ## NTLM in corporate networks ## Introduction When, a decade and a half ago, Microsoft began serious work on creating enterprise-wide centralized networks while working on the Windows NT operating system, the developers were given a very difficult and new task for those times - to implement single sign-on and One user technologies. - one password. One user - one password (one user - one password) means that the user should have only one password. A single password is used to access all network resources and protocols. Single sign-on (single sign-on) implies that this password is specified only once - when the user enters the network. One can argue a lot about the advantages and disadvantages of this approach, but one thing is certain - this approach is convenient for both users and application developers. The user does not have to remember a lot of passwords and enter them, and the developer does not have to think about how to organize user authentication. To do this, it was necessary to develop an authentication scheme that would allow any network application to transmit authentication data regardless of the network protocol. Thus was born NTLM and NTLMSSP (NTLM Security Service Provider) - a subsystem that allows any client-server application to use NTLM without knowing anything about its internal structure. This is not to say that Microsoft ignored the security requirements for the authentication protocol. In general, at that time, the NTLM protocol was not weaker than many of the protocols already in use, and in some ways even better. But now we can say with confidence that along with the NTLM protocol, a large number of problems related to its security have appeared. Part of the problem is because Microsoft had to maintain compatibility with existing LanManager networks for MS-DOS and Windows for Workgroups. Others are design errors and are due to the novelty of the problem being solved. Still others are purely cryptographic, because Back then, software vendors rarely had professional cryptanalysts on staff. The problems of the NTLM protocol have been widely discussed since 1995 and are still discussed today. There is a misconception that the Kerberos v5 authentication protocol used in Windows 2000 and Windows 2003 networks completely eliminates the NTLM problem. This is not so, because NTLM support on existing Windows networks is mandatory and any party involved in the authentication process can initiate the use of this protocol. For this reason, many problems of the NTLM protocol remain relevant in modern Windows networks and must be taken into account not only in the process of network administration, but also at the design stage. I have tried to collect in one place the information, thoughts, ideas and problems born from almost a decade of discussion on open mailing lists, as well as personal correspondence with many people to whom I would like to express gratitude for their help, answers to questions and patience - Urity (urity at securityfriday.com), Jesper Johansson (jesperjo at microsoft.com), Solar Designer (solar at openwall.com), offtopic (offtopic at mail.ru) Glenn Zorn (gzorn at cisco.com) and many more. Also used materials from the postings of Todd Sabin, Luke Kenneth Casson Leighton and Salman Niksefat. Due to natural laziness and the lack of exact titles and permanent URLs for most of the used posts, I will not make a bibliography at the end of the articles, let Google do it. We will not go into more technical details than is necessary to understand the problem, however, sometimes the reader will need some minimal understanding of authentication and authorization processes, programming and cryptography. To make life easier for the reader, there will be inserts of a nature in the article. **Authentication process for client-server applications on ****Microsoft networks** What happens after pressing Ctrl+Alt+Del? You are prompted by the Local Security Authority (LSA) for a username and password. Once entered, the password is hashed (a cryptographic hash is a one-way transformation that makes it impossible, or at least difficult to recover the original password from it), and the hash is placed in the LSA store. It doesn't appear in clear text anywhere else (in older versions of Windows, the password could be stored in clear text or with reversible encryption, because old versions of LanManager used clear text authentication, but we won't remember those times). In addition, the LSA store cannot be accessed directly using standard methods. The hashes are stored in the storage until the end of the session (and sometimes after, this will be discussed later). The NTLM protocol belongs to the challenge-response family of protocols. This means that neither the password nor its hash is ever passed access to a network drive from a telnet session or through a Web server if access via telnet or to the Web occurs with NTLM authentication. Theoretically, everything turns out great and absolutely safe. Even running the application with user rights, it is still not possible to get its password or even hash. And even by intercepting the session and replacing the server, it will not be possible to access other network resources. Let's look at all this from an implementation point of view. **Hashes ****NTLM** In the NTLM protocol family (as we will see below, there are several NTLM-like protocols), 2 types of hashes can be used: LM (LanManager) hash inherited from previous implementations of LanManager and NT (New Technology) hash created for the NTLM protocol. Accordingly, when a user logs into the system, as a rule, both of these hashes are taken from the password and stored. The first version of the NTLM protocol supported both keys for compatibility (the NT or LM key is usually referred to as the corresponding password hash). Later implementations only use the NT key, but by default an LM hash is still generated on login and placed in the LSA store. Let's take a look at both hashing algorithms. The LM key is obtained from the password in 8-bit OEM encoding (cp866 for Russia) using the DES algorithm. _For reference: DES is a symmetric block cipher that uses a 56 bit key to encrypt a 64 bit block of text. Actually, a 64-bit key is used inside the algorithm, but the key length is artificially reduced for incomprehensible reasons - a 56-bit key is by inserting an additional bit every 7 bits of the key. Because DES is relatively resistant to known-plaintext attacks, it can be used as a cryptographic hash function by using some known text as the plaintext and a hashable word as the key. The known text can be either random (in which case it's called a salt, and stored in a place with a password) or predefined, in which case it's called a Magic Word. The classic implementation of crypt() on Unix used the first approach, on Windows the magic word __KGS!@#$% is used (look at the keyboard: it must have been someone's password). When used as a hash function, __DES generates a 64 bit hash over 56 bit text._ Since DES allows you to get a hash only from a 7-character block, a password of 14 characters is actually used (a shorter password is padded with zeros), which is divided into two blocks of 7 characters each, from each of which the hash is calculated independently. The result is a 128-bit hash from two parts. The disadvantages of the algorithm are obvious. Independent calculation of two blocks allows their independent hacking, i.e. realistically every 64 bits of the hash can be attacked in order to recover the password. Moreover, to generate an LM key, the password is not case sensitive and characters are always used in upper case. This makes a brute force password recovery attack very effective (no more than 7 characters from a very limited alphabet). Moreover, a long password can be easier to recover than a shorter one. For example, for a password of 12 characters, the last 5 characters are first selected in a matter of seconds, after which an assumption is made about the structure of the password and the first 7 characters of the password are selected according to a more limited alphabet. Very fast implementations of DES using 64-bit arithmetic are currently known, making it completely unsuitable for cryptography. In general, recovering a password using an LM hash on modern technology is a matter of no more than a few days. In addition, the fixed magic word allows the use of a table of pre-computed key values, which makes it possible to recover the password from the LM hash in real time. The NT key is calculated using the standard MD4 hashing algorithm. The MD4 hash is taken from the password written in 16-bit Unicode encoding with the low endian byte sequence (i.e. the first byte is the character number on the page). The password is case-sensitive. MD4 has several cryptographic problems, the biggest of which is the short hash calculation time, which allows it to try out a sufficiently large number of combinations per unit of time, making it easier, for example, to attack a dictionary or select a weak combination of characters. _Hint: there are a large number of programs for recovering a password from a __NT or __LM key by dictionary selection or brute force - __John-__the-__Ripper, __LophtCrack, __Cain & __Abel. If both keys are present, the upper case password is usually recovered from the __LM key first, then the password case is recovered using the __NT key. This approach, in particular, is implemented in __Cain & __Abel (__http://__www.__oxid.__it), which is currently the most powerful and versatile tool for performing various tasks related to the detection of weak configurations, incl. and many __NTLM problems. We will repeatedly return to the possibilities of this utility. The fastest implementation of the __DES algorithm focused on cracking __LM keys in __Solar __Designer's __John-__the-__Ripper._ _Tip: You can disable the generation of __LM keys on the system by setting the value __NoLmHash to 1 in the registry key __HKEY___LOCAL___MACHINE\__SYSTEM\__CurrentControlSet\__Control\__Lsa_ _Despite what will be described below, it is strongly recommended to do this, at least to clear your conscience._ ## Who needs a broken key? As we have already said, NT and LM keys (hashes) are generated from the password when the user logs into the system, after which the password is not stored anywhere and is never used. A natural question arises: if we have NT and LM hashes on hand, can we use them, for example, for network authentication without password recovery in clear text? Obviously yes. Let's start with the simple case of open source. Let's try to modify the smbclient from SAMBA in such a way as to connect to a remote file server using an NT hash (as we know, recovering a password from an NT hash is much more difficult). It would be quite difficult to shovel through a dozen and a half megabytes of SAMBA sources if we did not know for sure that the NT key is an MD4 hash. We only need to modify the md4.c library in such a way that it does not hash something that already looks like a hash. For example, something that consists of 32 hexadecimal characters (as we remember, the key is 128-bit, and the password comes in Unicode encoding, i.e. each incoming character takes 2 bytes, it turns out 64 bytes at the input and 16 at the output). --- md4.c.orig 2004-04-04 11:37:00.000000000 +0400 +++ md4.c 2004-10-27 23:01:31.000000000 +0400 @@ -130,6 +130,21 @@ C = 0x98badcfe; D = 0x10325476; + + if(n == 64){ + int j; + unsigned char * hexd = (unsigned char *)"0123456789ABCDEF"; + for(j = 0; j<16; j++){ + if(!strchr(hexd, in[(j<<2)]))break; + if(in[(j<<2)+1])break; + if(!strchr(hexd, in[(j<<2)+2]))break; + if(in[(j<<2)+3])break; + out[j] = ((strchr(hexd, in[(j<<2)]) - (char *)hexd)<<4); + out[j] ^= (strchr(hexd, in[(j<<2)+2]) - (char *)hexd); + } + if(j == 16) return; + } + while (n > 64) { copy64(M, in); mdfour64(M); Let's check: bash$ smbclient //WIN2KSRV/shared added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0 Got a positive name query response from 192.168.1.2 ( 192.168.1.2 ) Password: _(entering 8846F7EAEE8FB117AD06BDD830B7586C)_ Domain=[WIN2KDOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb:\> Happened. Perhaps the most harmful question arises, is it possible to do a similar trick using Windows itself as a client? You can try to find the MD4 implementation used to get the hash when the user logs in and replace it (by modifying the binary code or by replacing the function in one of the many ways). A quick search through the system files shows that there are about 85 MD4 implementations in the SYSTEM32 folder (apparently programmers are paid by the amount of binary code), there are also especially suspicious ones, for example, in samlib.dll. There were also attempts to change keys directly in memory or storage, for example, in the article by Hernan Ochoa "Modifying Windows NT Logon Credentials": But, in fact, our article is theoretical and one experiment is enough to confirm the theory. The lesson to be learned is that the hash of a password is, in terms of the NTLM protocol, exactly the same as the password itself, the ability to obtain the hash means that the password can be fully exploited. ## Where is what stored LSA storage should not be confused with Protected Storage and SAM (Security Account Manager database). Protected Storage can store any data placed there by the application (names and passwords for remote access, e-mail, site authentication, and data for auto-filling forms). They can be retrieved from there in the same form in which they were put there at the request of the application through the standard API. There are no user password hashes. The SAM database stores local user accounts (on the domain controller - domain ones), including passwords in the form of NT and LM hashes, which is already somewhat more interesting. The local SAM database is a hive of the system registry (that is, part of the registry stored in a separate file). Previously, if the machine did not use the syskey utility, it was possible to extract local account password hashes directly from a file or from the registry. To extract hashes from a file, Dmitry Andrianov's samdump utility could be used, to extract from the registry - pwdump (Jeremy Allison). However, the syskey utility encrypts the stored hashes with the system key using the RC4 algorithm. The key can be stored on a floppy disk that must be inserted when the machine is booted, or on a disk - password-protected (it must be entered each time the machine boots) or in some reversible form. You can manage the storage of the system key using the syskey utility. Since Windows 2000 syskey with reversible key storage is enabled by default, which makes it difficult to extract hashes from SAM in a standard way. What will be retrieved is not actually the hash of the password. Pwdump2 (Todd Sabin) bypasses syskey security by reading password hashes through an internal API in the context of the winlogon process using a DLL injection technique. Pwdump3 (Phil Staubs) uses the same technique in combination with the Service API to start a process on a remote machine. All programs require either physical access to the computer or elevated privileges (for pwdump2 and pwdump3 - SeDebugPrivilege). Similar tricks were used to access the LSA store. Lsadump (PaulAshton) used the undocumented LsaRetrievePrivateData() API to retrieve data from the LSA store and could only run under the local system account. On later systems, Microsoft has made this feature completely unusable. Lsadump2 (Todd Sabin) uses the same DLL injection technique as pwdump2 to access LSA secrets via the lsass internal API and also requires SeDebugPrivilege. I should probably also mention cached logon credentials. By default, Windows stores data about the last 10 usernames and passwords typed. The main goal is to allow a domain user to log on to a computer even if there is no connection to the domain controller. Since there is no need to store the password hash directly (it will be calculated when the user logs in), some derived value is stored (MD4 on behalf of the user and the NT hash). Those. recovering the password hash is difficult, but one can try to attack the user's weak passwords. CachedLogonCredentials are also stored either in the LSA store or in the NL$ registry key. Unfortunately, the only known means of automatically accessing cached passwords, hashpipe (Todd Sabin) is not currently in the public domain. The specified tools are no longer supported by the developers. They, and other utilities that have been tested, including Cain & Abel, also do not provide reliable results on Windows XP SP2, as Microsoft has changed the way winlogon and lsass work, but for Cain & Abel it's probably just a matter of time. _Tip: You can manage __Cached __Logon __Credentials using domain policies or using the __CachedLogonCount registry key under __HKEY___LOCAL___MACHINE\__SOFTWARE\__Microsoft\__Windows __NT\__CurrentVersion\__Winlogon_ _It is very unpleasant if, for example, information about logging into a domain administrator's computer remains in cached identities (this is one of the reasons to manage a computer remotely). You can often see a recommendation to set __CachedLogonCount to 0, but the most optimal value seems to be 1 - this allows the last user to log in in the absence of a network connection - i.e. the one that usually works with a computer ._ **Actually ****NTLM** There are currently two major versions of NTLM. The first version of NT LanManager was 0.12, often referred to as NTLM v1 and NTLM v2. In addition, there are several NTLM-based dialects, such as the MS-CHAPv2 authentication protocol (MS-CHAP is pure NTLM 0.12). We will dwell on NTLM 0.12 in more detail, because we will be interested in his so often discussed cryptographic vulnerabilities. So, NTLMSSP generates of security data (security blob) that are exchanged between client and server applications. The exchange takes place in several stages, and for NTLM 0.12 it looks like this: 1. The client sends an authentication request to the server. 2. The server responds with a packet indicating the selected NTLM authentication and whose EncryptionKey field contains a 64-bit random challenge. 3. The client sends a message containing the fields AccountName (account), PrimaryDomain (account domain), CaseInsensitivePassword (case insensitive password, actually an LM response), and CaseSensitivePassword (case sensitive password, actually an NT response). Both responses are 192-bit and are calculated based on the NT and LM keys using the same algorithm. If there is no corresponding key, then the corresponding answer will be zero. Let's illustrate the response generation algorithm using the example of the NT key 8846F7EAEE8FB117AD06BDD830B7586C (as we remember, it is 128-bit) with a 64-bit server request 0123456789ABCDEF. ![](ntlmrus1.gif) NT answer DD5428B01E86F4DFCABEAC394946DBD43EE88F794DD63255. It should immediately be evident what is wrong with this algorithm - the problem is the same as when calculating the LM hash, all three DES blocks are calculated independently. This means that they can also recover independently from a known request and response. For a modern PC, the time it takes to recover one block of a password hash using brute-force search is about several weeks and does not depend on the complexity of the password. If there is an LM response, then again, an attack is possible on recovering the second half of the password in clear text, after which the first part is restored even by exhaustive search in a few days. From this, combined with the fact that having a hash we do not need a password in clear text, the unambiguous conclusion follows - NTLM 0.12 and MS-CHAP should not be used for authentication in networks where traffic can be intercepted. In addition, if it is possible for an external untrusted server to initiate a user login, then it can use the submitted response to recover the user's key. Moreover, due to the choice of a query (for example, only zeros), key hacking can be organized in real time according to pre-calculated tables. The MS-CHAPv2 Remote Access Authentication Protocol is just an extension of the MS-CHAP protocol and thus NTLM 0.12. The changes are as follows: the client also generates a random request for the server, to which the server must respond, i.e. client and server authentication is mutual. In addition, the server request enters the response generation algorithm in a modified form (the algorithm itself remains the same) - SHA1 is taken from the server request, client request and username. This does not affect the complexity of the hash recovery attack, since SHA1 needs to be calculated only once, and then the same iteration algorithm is used. The only positive point from the point of view of cryptography is that in the event of a server spoofing, you cannot use pre-calculated tables to restore the hash by choosing a previously known query. It follows from this that MS-CHAPv2, which is often used for authentication, for example, PPTP connections, should also in no case be used for authentication over untrusted communication channels. Today, the only more or less strong remote access password authentication protocol is PEAP (Preotected EAP), which, unfortunately, is poorly supported, which makes it almost impossible to use, for example, PPTP tunnels with MPPE encryption, even with a large encryption key, for building VPN networks, because MPPE encryption keys are generated based on the NT key. The ability to recover an NT key from authentication data also makes it possible to recover transmitted data in a very short time, regardless of the length of the session key. NTLMv2 also uses mutual client and server authentication, but uses the much stronger HMAC-MD5 algorithm to get the response. _For reference: __HMAC-__MD5 generates a hash based on text (__text) and key (__key) using the standard __MD5 hash using the following algorithm:_ _HMAC_MD5(text,key) = MD5 (key xor opad . MD5(key XOR ipad.text))_ _Where '.' Means concatenation, __ipad = 0x36363636363636363636363636363636, __opad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C_ The answer is calculated as follows: 1. Client generates a key (NT2 key) using HMAC_MD5 with NT key as key and username concatenated with Unicode domain name as text. 2. The client generates a piece of data (blob), which includes random data, a timestamp, a NetBIOS name, etc., about 64 bytes in total, the length may vary. 3. blob is concatenated with server response 4. HMAC-MD5 is calculated with the NT2 key obtained in the first step as the key and blob as the text. 5. result (4) is concatenated with blob (2). What happened is the answer. Such an algorithm for generating a response when using strong passwords removes almost all cryptographic problems, which makes NTLMv2 quite resistant to passive listening attacks, however, of course, it remains possible to select weak passwords using a dictionary or brute force. _Hint: __Cain & __Abel implement almost all of the above attacks. In addition, the built-in __arp __poisoning sniffer allows you to intercept __NTLM authentication data even in switched networks and automatically transfer all the necessary data to the cryptographic analysis subsystem for various types of cryptographic attacks._ _Tip: You can control the allowed authentication protocols and disable authentication protocols other than __NTLMv2 using the registry or domain policies. The LMCompatibilityLevel registry key under HKLM\System\CurrentControlSet\Control\LSA is responsible for this. Possible values are:_ 0. _Send __NT and __LM responses_ 1. _NTLM session security (does not affect authentication)_ 2. _NTLM authentication. __LM response is not generated by the client. Does not affect the server._ 3. _NTLMv2 authentication, client does not use __NTLM 0.12_ 4. _NTLM is required, server does not accept __LM response_ 5. _NTLMv2 required, server does not accept __NTLM 0.12 authentication._ _As the name suggests, setting a high LMCompatibilityLevel may affect older OS clients._ **Attacks ****NTLM relaying** The NTLM protocol was specifically designed to provide transparent user access to resources without unnecessary questions and at the same time not depend on application and network protocols. A client application that supports NTLM simply passes the authentication data (blobs) generated by the security subsystem to the server application. In this case, there is no binding of authentication data to the network protocol, i.e. parameters such as IP address and port. This allows NTLM authentication to pass through a proxy server or router with address translation, but it also allows NTLM relaying attacks where an attacker with no direct access to network data between the client and server can, however, intercept all transmitted data. The only prerequisite for this (except for communication with the client and server at the network level, of course) is the ability to initiate a client connection using a protocol that supports transparent NTLM authentication. Thus, without direct access to the communication channel, it is possible to organize a man-in-the-middle situation. ![](ntlmrus2.gif) So: the attacker provokes the client to connect to himself using a protocol that allows NTLM authentication. After that, the attacker connects to the server using any protocol that allows NTLM authentication. This does not have to be the same protocol that the client is using, as authentication data is in no way tied to the application protocol and network parameters. For example, a client can connect to an attacker using the CIFS (SMB) file protocol, and an attacker can connect to a server using telnet. After that, the authentication data (blobs) are transmitted to the attackers between the client and the server. At the end of authentication, the client considers that it is successfully authorized by the server, the server considers that it has authorized the client, and the attacker has two authorized channels - he acts on behalf of the server for the client and on behalf of the client for the server. Does the use of NTLMv2 save, at least to some extent, from NTLM relaying attacks? Unfortunately no. Since the attacker does not use cryptanalysis, the cryptographic strength of the algorithm has no effect. The presence of mutual authentication of the client and server does not affect either. The attacker forwards all the authentication data between them, so the extra packet - the server's response to the client's request - also gets there. For some protocols, Microsoft is advised to use packet signing, such as SMB signing for CIFS/SMB. Unfortunately, SMB signing saves only in one situation - it makes it difficult to connect to a CIFS server that requires a signature. This makes it impossible to use NTLM interprotocol relaying to connect to a CIFS server. In the case of relaying from a CIFS client to a CIFS server, the attacker has access to all passing data. The client and the server sign the data, but again this signature is not tied to the network protocol, the attacker simply sends the data unchanged. This prevents the attacker from interfering with the transmitted data (for example, requesting his file directly from the server), however, if the attacker has gained the ability to control the behavior of the client, he can force the client to request the required file. Currently, there are many ways to control the behavior of a client application. For example, by directing the user to an HTML page containing

, where A.B.C.D is the attacker's address, you can force the client to connect to the attacker's SECRETSHARE network folder using the CIFS protocol and request a largesecret file .doc The attacker can redirect this request to the server on behalf of the client. In this case, all requests will be signed to clients if SMB signing is used. NTLM relaying attacks have been discussed by various authors. DilDog in 2000, due to a problem with NTLM authentication in telnet (Internet Explorer by that time already had the option not to perform transparent NTLM authentication in the Internet zone). 3APA3A in 2001 in connection with Outlook Express SPA authentication. Salman Niksefat and Haamed Gheibi in 2003 demonstrated a practical implementation of NTLM relaying from CIFS to CIFS when the client and server are the same machine. **How to defend against ****NTLM attacks** The main remedy for various eavesdropping attacks is, of course, the encryption of traffic between hosts. You can find a sufficient number of guides for implementing traffic encryption using IP security policies. To prevent NTLM relaying attacks using the CIFS protocol, the use of this protocol should be restricted. Firstly, connections via the NetBIOS (TCP/139) and CIFS over TCP (TCP/445) protocols should not be passed not only from the external network to the inside, but also from the internal network to the outside. For many reasons, including this one, access to Internet resources for users should be organized not with the help of address translation, but with the help of a proxy server. The NTLM relaying attack using CIFS can also be used on the internal network to elevate privileges. To prevent this, network-level communication between client computers should be restricted. Ideally, clients should only be able to communicate with the servers they need to connect to. In Windows 2000/XP/2003 networks, such a network structure is easily implemented through the use of IP domain security policies. To do this, a rule is created that allows you to block packets: ![](ntlmrus3.gif) ![](ntlmrus4.gif) A description of the server network is created ![](ntlmrus5.gif) ![](ntlmrus6.gif) A policy is created that allows server traffic and prohibits everything else: ![](ntlmrus7.gif) ![](ntlmrus8.gif) Now this rule can be applied to the local computer or to all client computers using Active Directory policies. ![](ntlmrus9.gif) Eliminating the possibility of NTLM attacks in CIFS will not completely eliminate the attacks. There are a large number of protocols that support NTLM authentication, and the development of various services, incl. and RPC over HTML makes filtering out NTLM authentication even more difficult. Hint: As a solution, it can be advised not to allow access to services accessible from the outside with accounts used on the internal network. For external resources, it is better to use certificate-based authentication, in the internal network - two-factor authentication. ## Conclusion I hope this article will help you consider the features of the NTLM protocol when building the architecture and security scheme of your network, or just understand what it is.

3APA3A : NTLM in corporate networks