This blog post will explain NTLM's main security weaknesses. From common attack techniques to specific vulnerabilities.
NTLM is a rather veteran authentication protocol and quite vulnerable for relatively easy to initiate attacks. The fact that it is not secure, doesn't make it easier to move to a better protocol (such as Kerberos), since many functions are dependent on it. In fact, Microsoft still supports it even in its recent versions.
Microsoft came out with NTLM version 2 with better security options. Although it did improve its security, even the new version is still very open for attacks. Microsoft warned against using NTLM in applications altogether since “NTLM does not support any recent cryptographic methods, such as AES or SHA-256.”
Since it is almost impossible to completely neglect NTLM, it is highly important to manage it correctly: knowing where NTLMv1 and NTLMv2 are in use, move to better authentication where possible, perform other configuration changes help elevate the security in NTLM authentication.
In this blog post we will explain:
4.Vulnerabilities in components the suppose to elevate NTLM security- MIC, EPA, LMv2 & NTLMv2.
How NTLM works:
NTLM protocol is used for establishing an authenticated communication between a client and a server. The client must authenticate itself before connecting the server, which validates that the client is indeed a legitimate client and not an attacker.
The authenticated connection has 3 steps:
1.The client requests to authenticate in front of the server (NTLM AUTHENTICATE).
2.The server responds with a challenge (NTLMSSP_CHALLENGE) - a random sequence of characters.
3.The client encrypts the challenge using its secret key and sends it back.
During the authentication process, the client uses an MD4 fingerprint as a DES key (if it is NTLMv1 that is in use) of its password to encrypt the challenge. In any scenario possible, a plaintext password is never used during the authentication process. The only version used is a hashed version, called the NT hash, which is a simple hash of the plaintext password.
When the server receives the client's response, there are two scenarios possible:
When the client is a local account:
When this is the case, the server already knows the account and has a copy of the account's secret. The server will then send an encrypted challenge using the client's secret key, or the secret key with an MD4 hash. After the client responds, the server will check if he used the right secret to authenticate it.
The local accounts' hashed passwords (in an encrypted version) are stored in the Security Account Manager (SAM) database, which you access through the registry only if you are configured as SYSTEM. Note that although the hashes are stored encrypted, the information needed to decrypt them is also stored in the SAM.
When the client is a domain account:
A domain account's NT hash is stored in the domain controller. The server must use the domain controller (DC) to check if the client's answer is valid. The communication between the server and the DC is done using the Netlogon service. The servers will send the DC several details about the client and the DC will look for the client's NT hash in a file called NTDS.DIT.
Once the DC gets the hash, it will know the expected response, compare it to the client's response and send the server the information.
There are two iconic attack techniques for this protocol- NTLM Relay (using Man-in-the-Middle technique) and Pass the Hash. In addition, there are several vulnerabilities in external protocols that suppose to better NTLM security. We will cover them all in the following post.
NTLM relay (man in the middle):
NTLM relay attack uses NTLM basic authentication method as an attack vector, therefore it will be relevant as long as NTLM is in use.
In this attack method, the attacker uses a Man-in-the-Middle technique to relay information between the client and the server. The attacker manages to position himself in a way that the client will assume he is the server, and the server will assume he is the client.
During the attack, the attacker gets exposed to the information transmitted between the client and the server. There is no use in the client's password in plain text during the client-server communication, but only in a hashed version of it. But when understanding the authentication process, it's easy to see that stealing the hash is the same as stealing the password itself, since you can get authenticated by using it. In fact, having the NT hash is as useful as having the password in cleartext.
The server has no idea that the one communicating with him is an attacker and not a client, and the client has no clue that the information provided by him is leveraged by an unwanted visitor in this communication. Eventually, the attacker authenticates in front of the server, gaining the client's abilities to perform tasks and reach the server's resources.
NTLM Pass the Hash:
NTLM Pass the Hash attack is based on the NTLM relay method.
When configuring a new client's workstation using a master template, all clients that had configured using this template have the same account details. If one of these accounts is compromised and the attacker manages to put his hands on its NT hash, he can then start checking it on any account he wishes, hoping this account's template is the same as the one that he stole the hash from.
Another option for the attack to use this hash is by leveraging the user's grouping. Once the attacker holds an NT hash, he can authenticate all hosts as a part of the groups that the original user is in. For example, if the user with the stolen hash is set as admin in certain groups, the attacker can leverage it and authenticate as an admin in whichever host he wants. Going back to the first scenario, whenever a master template is implemented, its grouping will also be added to the host's configuration.
Attacks using NTLM's extended security components:
The following technique leverages NTLM Relay and possible by exploiting one of three components that were developed to mitigate the NTLM Relay attack.
Message Integrity Code (MIC) vulnerability:
The MIC feature is an optional feature that aims to improve NTLM security, by preventing attackers from tempering NTLM messages.
Session signing:
One of the most used ways to mitigate NTLM relay attacks is by session signing. When a communication session between a client and a server is signed, attackers can't hijack the session, since they can't retrieve the required session key to the server.
NTLM supports SMB, LDAP, and HTTP (rarely used) for session signing. When using SMB, NTLM relay is only possible when relaying SMB authentication requests. New NTLM versions added a feature to protect against this option- the MIC field.
You can note if the MIC is in use by checking the msvAvField in the NTLM_AUTHENTICATE message. If flag 0X2 exists, it means that the MIC is being used to protect from the NTLM relay.
Bypassing the MIC will eventually allow modifying any field in the NTLM message flow. When modifying the signing requirements, attackers can relay successful authentications to another server, while making the server ignore any signing requirements. Eventually, the attacker will use this information to move laterally in the infrastructure.
Drop the MIC 2 (CVE-2019-1166):
The msvAvFlag is signed by a hash password so that it couldn't be modified. However, in unpatched systems, you could trick the server into thinking that the message does not include a MIC.
If the attacker sets the msvAvFlag field into zero, it will be injected into the authentication message together with the correct msvAvFlag field (0X2). When a server receives an authentication message with two different msvAvFlag fields it only takes the first field- the tampered field that contains zero. As a result, the server thinks that there is no MIC, and the attacker can now initiate his desired attack.
EPA bypass vulnerability:
The EPA mechanism is used for channel binding to add security to the NTLM service. The EPA bunds between Windows authentication process and TLS session to make sure that all the packets that are sent over the TLS channels origins in sources who know the client's secret. The way it achieved in NTLM is by adding a specific channel binding AV pair (attribute/value pair) in the NTLM_AUTHENTICATE message. This way, communication can't be tampered with by an attacker.
This flaw is based on the MIC flaw. After initiating a MIC bypass, the attacker can change the NTLMSSP_CHALLENGE message that contains the Target Info field. The clients echo all the AV pairs in the Target Info field, including the ones in the AV pairs in the NTLMSSP_AUTHENTICATE message.
Any attacker that can modify NTLM messages (after bypassing MIC) can use a channel binding of their choice to send a malicious NTLM_CHALLENGE to attack a server, even if it is protected by EPA.
LMv2 & NTLMv2 vulnerability (CVE-2019-1338):
Although LM is rarely used during NTLM authentication due to its security issues, some clients still rely on its newer version- LMv2 (Firefox, Linux machines, etc). Using LMv2 combined with an NTLMv2 response allows attackers to perform NTLM relay while bypassing several relay mitigations (such as MIC and EPA).
The vulnerability sources in the differences between the target server and the DC validation. When both NTLMv2 and LMv2 are used, the server relies on the AV pairs sourced in the NTLMv2, while the DC relies solely on the LMv2 response. An attacker can use this fact and modify the NTLMv2 response when relaying the authentication against the target.
