The Preempt research team found two critical vulnerabilities in Microsoft, sourced in three logical flaws in NTLM, Microsoft’s authentication protocol. The vulnerabilities potential outcome is allowing remote execution of malicious code on any Windows machine in all versions. Another attack vector this vulnerability contains is authenticating to any web server that supports Windows Integrated Authentication (WIA) such as Exchange and ADFS.
NTLM attacks are especially relevant to Active Directory environments. One of the most common attack vectors is NTLM Relay, where the attacker compromises one machine and then spreads laterally to other machines by using NTLM authentication directed at the compromised server.
Although Microsoft has previously developed several mitigations for NTLM Relay attacks, three major flaws were discovered in those mitigations.
Here are the mitigations and the result of bypassing them:
-
The Mitigation: The Message Integrity Code (MIC) field ensures that attackers do not tamper NTLM messages.
The MIC is an HMAC_MD5 applied to the concatenation of all NTLM massages using the session key, which is known only to the account initiation of the authentication and the target server. As a result, an attacker who tries to tamper with one of the massages will not be able to generate a similar MIC and the attack will fail.
The flaw: to overcome the MIC protection attacker should perform the following actions:
- Unset the signing flags in the NTLM_NEGOTIATE message (NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN)
- Remove the MIC from the NTLM_AUTHENTICATE message
- Remove the version field from the NTLM_AUTHENTICATE message (removing the MIC field without removing the version field would result in an error).
- Unset the following flags in the NTLM_AUTHENTICATE message: NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN, NEGOTIATE_KEY_EXCHANGE, NEGOTIATE_VERSION.
Consequences: This bypass means that all NTLM authentication requests are vulnerable to Relay attacks, regardless of the protocol which carries them. attackers can relay NTLM authentication to any server in the domain, including domain controllers, while establishing a signed session and performing remote code execution. This could result in full domain compromise if the relayed authentication is of a privileged user.
-
The mitigation: Enhanced Protection for Authentication (EPA) prevents attackers from relaying NTLM messages to TLS sessions.
The EPA is a channel binding mechanism. The EPA ensures that all packets the are sent over a TLS channel are sent party that knows the client's secret. This is achieved through binding the Windows authentication process with the TLS session by requiring the client to sign a derivative of the server's certificate using the GSSAPI security.
The flaw: this flaw is a further step of the MIC flaw. With the MIC missing, attackers can tamper with the NTLMSSP_CHALLENGE message. The NTLMSSP_CHALLENGE massage contains a TargetInfo field and the NTLM clients usually echo all AV pairs in the TargetInfo and include them in the AV pairs in the NTLMSSP_AUTHENTICATE message. This means that a malicious NTLM_CHALLENGE can be sent with a channel binding of the attacker’s choice.
Consequences: this is a serious attack vector as EPA is the only line of defense in several critical servers such as AD-FS and OWA. Since AD-FS and OWA are often open to the internet, an attacker could compromise these servers with no infected machines, just by sending malicious emails. The attacker can then make users authenticate via NTLM and relay their credentials.
-
The mitigation: SMB Session Signing prevents attackers from relaying NTLM authentication messages to establish SMB and DCE/RPC sessions.
Not all clients are vulnerable to an NTLM attack. Windows SMB clients were resilient to the attack. SMB clients would not accept an NTLM_CHALLENGE message without a target present in the Target Info field.
All web clients that were tested (IE, Chrome, Firefox) were vulnerable to the attack and responded to the modified challenge.
Consequences: to all vulnerable servers, the attacker can initiate a signed SMB session and execute code remotely from his server.
Mitigation strategies:
- Patch- although servers and workstations should be properly patched, you should note that patching alone is not enough. A company should also need to change its' configuration policy to fully mitigate this vulnerability.
- Configuration-
Enforce SMB Signing - turn on SMB Signing on all machines in the network.
Block NTLMNv1- NTLMv1 is considered significantly less secure than its more recent version, the NTLMNv2.
Enforce LDAP/S Signing- to prevent NTLM relay in LDAP, enforce LDAP signing and LDAPS channel binding on domain controllers.
Enforce EPA- to prevent NTLM relay on web servers, harden them to accept only requests with EPA.
- Reduce NTLM usage- even after all measures were taken. The best thing you can do is to simply reduce the NTLM usage. As NTLM poses a significant risk, it is recommended that you remove it where it is not needed.
Mitigating NTLM vulnerabilities without harming production:
Applying the recommended actions for mitigating NTLM vulnerability can cause extensive damage to your servers' functionality. Before you implement any of them, you should perform lab testing and understand the impact of any configuration change on your production environment. This process is costly and very time consuming, but inevitable. Unless you automate the process with CHS by CalCom. CHS has the unique ability to learn your production environment and report on any unwanted consequence before the change is made. By doing that, CHS eliminates both the need for lab testing and the concern about outages. Using CHS to harden your servers will make you resilient to vulnerabilities such as these NTLM vulnerabilities, hassle-free.
