Security Advisory: Active Directory Open to More NTLM Attacks
By: Yaron Zinar and Marina Simakov
Drop The MIC 2 (CVE 2019-1166)
& Exploiting LMv2 Clients (CVE-2019-1338)
Today, on October 2019 Patch Tuesday, Microsoft released patches for CVE 2019-1166 and CVE-2019-1338, two important vulnerabilities discovered by the Preempt Research Team:
CVE 2019-1166: This vulnerability allows attackers to bypass the MIC (Message Integrity Code) protection on NTLM authentication and thereby modify any field in the NTLM message flow, including the signing requirement. This bypass allows attackers to relay authentication attempts which have successfully negotiated signing to another server while tricking the server to entirely ignore the signing requirement. All servers that do not enforce signing are vulnerable to this attack. This is the second MIC bypass vulnerability found by the Preempt team; the first one can be found here.
CVE 2019-1338: This vulnerability allows attackers to bypass the MIC protection, along with other NTLM relay mitigations such as Enhanced Protection for Authentication (EPA) and target SPN validation for certain old NTLM clients that are sending LMv2 challenge responses. This attack allows attackers to use NTLM relay to successfully authenticate to critical servers such as OWA and ADFS and steal valuable user data.
NTLM relay is one of the most prevalent attacks on the Active Directory infrastructure. The most important defenses against NTLM relay are server signing and Enhanced Protection for Authentication (EPA); you can read more about these mitigations in June’s security advisory. When these defenses are strictly enforced, the network is fully protected from NTLM relay attacks. However, due to various reasons ranging from configuration errors and unsupported applications to more malicious intent, most networks are not fully protected. Modern NTLM implementations include special MIC protection. When the MIC is used by an NTLM client, launching NTLM relay attacks is much more difficult and in many cases: impossible.
For an overview of the MIC and the first vulnerability we discovered, you can review our previous blog post. In CVE 2019-1166, we were able to bypass the MIC protection, overcoming the fix for our previously disclosed vulnerability on the issue. In CVE-2019-1338, we were able to bypass the MIC protections, along with other NTLM relay mitigations such as EPA and the GPO for SPN target name validation for clients which add an LMv2 response to their NTLM authentication.
CVE 2019-1166 – Drop The MIC 2
The MIC is an optional field provided by NTLM clients to ensure attackers cannot tamper with NTLM messages (e.g., using NTLM relay). The presence of the MIC is announced in the ‘msvAvFlag’ field in the NTLM_AUTHENTICATE message (flag 0x2 indicates that the message includes a MIC) and it should fully protect servers from attackers who attempt to remove the MIC and perform NTLM relay.
Figure 1 – The ‘flags’ field indicating that the NTLM_AUTHENTICATE message includes a MIC
In our previous disclosure (CVE-2019-1040), we presented a way to remove the MIC from the message without tampering with the ‘msvAvFlag’ field, simply by dropping it from the message along with the version field and some additional negotiation flags. After the fix, removing the MIC is no longer an option due to the validation performed on the ‘msvAvFlag’ field. However, we were able to find an additional way to trick the server into believing the message does not include a MIC, allowing us to modify any stage of the NTLM authentication flow (for example, remove the signing requirement).
The key to this new vulnerability is the understanding that the MIC is an optional field and the only way NTLM servers can validate that this field is present is by inspecting the flags in the ‘msvAvFlag’ field. In addition, since the ‘msvAvFlag’ field is signed by the user’s password hash, attackers have no way of modifying it.
However, there is still a way they can bypass the MIC protection and modify any part of the NTLM negotiation stage, such as the signing requirement. This can be done in a similar manner to the technique we have disclosed in CVE-2019-1019 in our EPA bypass vulnerability. The EPA bypass vulnerability allows attackers to simply inject a ‘msvAvFlag’ field into the av_pairs in the TargetInfo field of the NTLM_CHALLENGE, which would be echoed back in the NTLM_AUTHENTICATE message. If attackers set the ‘msvAvFlag’ field to zero, this field would be injected into the NTLM_AUTHENTICATE message, along with an additional ‘msvAvFlag’ field stating the correct value calculated by the client (which would be set to 0x2 if a MIC was added to the message).
The last question that remains: what will the attacked target do when receiving an NTLM_AUTHENTICATE message with two different ‘msvAvFlag’ fields? Luckily for the attackers (and not so lucky for everyone else), the server will only take into consideration the first field – the one injected by the attackers stating that a MIC is not present in the message. All that is left for the attacker is to simply remove the MIC from the NTLM_AUTHENTICATE message and bypass any security feature protected by this field.
Figure 2 – NTLM Authenticate message with injected msAvFlags field
The exact attack flow to bypass session signing while removing the MIC is as follows:
- Unset the signing flags in the NTLM_NEGOTIATE message (NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN)
- Inject a rogue ‘msvAvFlag’ field in the NTLM_CHALLENGE message with a value of zeros.
- Remove the MIC from the NTLM_AUTHENTICATE message.
- Unset the following flags in the NTLM_AUTHENTICATE message: NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN, NEGOTIATE_KEY_EXCHANGE, NEGOTIATE_VERSION.
We believe that this is a serious attack, as it adds unnecessary risks to SMB relay in most networks and those risks are further compounded with the additional danger of bypassing EPA in certain NTLM clients.
CVE-2019-1338 – Exploiting LMv2 Clients
Most clients today do not send an LM response during an NTLM authentication flow since it is considered less secure than NTLM. However, there are still some clients that send LM responses (specifically, LMv2 which is considered more secure) such as Firefox on MacOS or Linux machines. While it is no trivial feat to perform a brute-force attack on an LMv2 response, we discovered that the consequences of sending an LMv2 response along with an NTLMv2 response are more severe than we imagined. If a client sends both responses, attackers can relay the authentication while bypassing various NTLM relay mitigations such as the MIC, EPA, or the GPO for SPN target name validation.
When a client sends both LMv2 & NTLMv2 responses, the target server relies on values in the av_pairs inside the NTLMv2 response for various security features (such as the channel_bindings for the EPA protection or the av_flags for the MIC protection). However, when the Domain Controller receives such a response, it validates only the LMv2 response. This means a relayer can target clients which send both LMv2 & NTLMv2 responses and modify any part of the NTLMv2 response when relaying the authentication against the attacked target. The heart of the problem lies in the fact that the target server relies on values in the NTLMv2 response, however, the DC does not validate the NTLMv2 response if an LMv2 response is present.
The impact of these vulnerabilities is far-reaching and, in some cases, can cause full domain compromise of a network. For example – by performing NTLM relay to a sensitive server that does not enforce SMB signing, or by performing NTLM relay to LDAP on a Domain Controller in order to modify sensitive AD objects (LDAP signing will be enforced by default only from January 2020). All Active Directory customers with default configurations are vulnerable to such attacks. Moreover, organizations that do not block LM responses and have clients who still send these default responses are vulnerable to targeted attacks on these clients to bypass additional NTLM protections. Despite Kerberos being the more prevalent authentication protocol in most organizations, NTLM is still enabled and thus abused by attackers to exploit the vulnerabilities that we have described above.
How can you protect your network?
- Enforce NTLM mitigations. In order to be fully protected from NTLM relay attacks, you will need to enable server signing and EPA on all relevant servers.
- Patch! Make sure your systems are fully protected with the latest security updates.
- Apply advanced NTLM relay detection and prevention techniques similar to the ones disclosed by Preempt in our Black Hat 2019 talk (a free encore presentation can be found here).
- Some NTLM clients use weak NTLM variations (e.g., don’t send a MIC). This puts your network at a greater risk of being vulnerable to NTLM relay. Monitor NTLM traffic in your network and try to restrict insecure NTLM traffic.
- Get rid of clients sending LM responses and set the GPO Network security: LAN Manager authentication level to refuse LM responses.
- NTLM is not recommended to use in general as it poses some security concerns: NTLM relay, brute force, and other vulnerabilities. You can read about general NTLM risks here. As a rule of thumb: try to reduce NTLM usage in your network as much as possible.
How Preempt can Help
Preempt constantly works to protect its customers. Those who have deployed Preempt have been consistently protected from NTLM relay attacks. The Preempt Platform provides full network NTLM visibility, allowing you to reduce NTLM traffic and analyze suspicious NTLM activity. In addition, Preempt has innovative industry-first deterministic NTLM relay detection capabilities and has the ability to inspect all GPO configurations — and will alert on insecure configurations.
This configuration inspection is also available in Preempt Lite, a free, self-serve version of the Preempt Platform. Download Preempt Lite and within an hour or two, verify which areas of your network are vulnerable.
Posted by Preempt Research Team on October 8, 2019 10:00 AM