Shulou(Shulou.com)05/31 Report--

How to analyze the vulnerability of Windows NTLM tampering? in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

On June 11, 2019, Microsoft released a June security patch update. In this security update patch, the CVE-2019-1040 vulnerability is fixed. An attacker can exploit this vulnerability to bypass MIC (Message Integrity Code) in NTLM. An attacker can modify authenticated traffic that has been negotiated for signature and then relay it to another server while completely removing the signature requirement. Through this attack, the attacker can control any machine in the domain (including the domain control server) when he has only one ordinary domain account.

Loophole background

NTLM relay is one of the most common attacks against Active Directory environment. An important mitigation measure for this attack technology is to sign the server. When the user establishes a signing session with the server, the attacker cannot hijack the session if he cannot retrieve the required session key. By default, however, only domain-controlled servers enforce SMB signing, which makes other sensitive servers in the domain vulnerable in many cases.

Figure 1 NTLM Relay

In SMB, negotiate session signing by setting the "NTLMSSP_NEGOTIATE_SIGN" flag in the NTLM_NEGOTIATE message. If attackers try to relay this NTLM authentication, they will need to ensure that signatures are not negotiated. One way is to relay to protocols that do not manage session integrity by relaying to NTLM messages, such as LDAPS or HTTPS. But not every machine will turn on such an agreement. However, the SMB protocol is often opened in the local area network, and there are many loopholes that can easily cause code execution. Therefore, the focus of NTLM relay attacks is to forward SMB authentication requests to other SMB servers. In order to successfully execute such a relay, the attacker needs to modify the NTLM_NEGOTIATE message and unset the "NTLMSSP_NEGOTIATE_SIGN" flag.

Figure 2 NTLM_NEGOTIATE message indicates whether to negotiate SMB signature

In SMB, session signing is required if both sides of the communication support signing by default. To ensure that the data is not tampered with by attackers during the NTLM negotiation phase, Microsoft adds an additional field, MIC, to the final NTLM authentication message. However, there is a flaw in Microsoft's handling of this field: it allows authentication messages without MIC.

MIC (Message Interity Code) message integrity verification

NTLM authentication consists of three message types: NTLM_NEGOTIATIE,NTLM_CHALLENGE,NTLM_AUTHENTICATE. To ensure that it will not be maliciously tampered with during transmission, an additional MIC field has been added to the NTLM_AUTHENTICATE message. A MIC is a concatenated HMAC_MD5 that applies to all three NTLM messages using a session key that is known only to the account that initiated the authentication and the target server. Therefore, any attempt to tamper with one of the messages can not generate the corresponding MIC to ensure the security of the transmission.

Figure 3 the "MIC" field prevents NTLM messages from being modified

The MIC exists in the 'msvAvFlag' field of the NTLM_AUTHENTICATE message, and the flag 0x2 indicates that the message includes MIC. It should protect MIC from being deleted. However, Microsoft Microsoft server cannot fully implement this mechanism and allows NTLM_AUTHENTICATE messages without MIC. This provides conditions for subsequent NTLM relay attacks.

Figure 4 'flags' field indicates that the NTLM_AUTHENTICATE message includes MIC

Vulnerability Analysis 4.1 attack ideas

Because Microsoft allows NTLM_AUTHENTICATE messages without MIC, attackers can relay after obtaining legitimate authentication. The main purpose is to relay SMB to LDAP.

First initiates authentication to a Windows server (such as Exchange), and after obtaining legal authentication, relays the authentication to the domain control server through LDAP, and a series of operations can be performed in ActiveDirective with the victim rights of the relay.

In an Exchange scenario, you can obtain DCSync permission, which is the basis of PrivExchange vulnerability exploitation.

In the Resource Based Constrained Kerberos scenario, you can use this mechanism to gain the privileges of the victim host, and then access the server with administrator privileges.

The process for MIC that requires relay authentication is as follows:

1. Unset the signature flag (NTLMSSP_NEGOTIATE_ALWAYS_SIGN,NTLMSSP_NEGOTIATE_SIGN) in the NTLM_NEGOTIATE message

two。 Remove MIC from a NTLM_AUTHENTICATE message

3. Delete the version field from the NTLM_AUTHENTICATE message (deleting the MIC field without deleting the version field will cause an error)

4. Unset the following flag in the NTLM_AUTHENTICATE message: NTLMSSP_NEGOTIATE_ALWAYS_SIGN,NTLMSSP_NEGOTIATE_SIGN,NEGOTIATE_KEY_EXCHANGE,NEGOTIATE_VERSION.

4.2 ways of attack

1. Using any AD account, connect to the victim host Exchange server through SMB and trigger a bug of SpoolService. Then relay to LDAP using a ntlmrelayx.py script that is publicly available on the Internet. Using LDAP authentication for relays, an attacker can gain DCSync privileges and then use DCSync to dump all password hashes in AD.

two。 Using any AD account, connect to the victim host Exchange server through SMB and trigger a bug of SpoolService. Then relay to LDAP using a ntlmrelayx.py script that is publicly available on the Internet. The attacker uses the LDAP authentication of the relay to obtain the relevant permissions in the Resource Based Constrained Kerberos, and then the attacker authenticates as any user on the victim host server. After successful verification, you can proceed with the next attack and even take control of the entire Windows domain.

Scope of influence

Currently affected Windows versions:

Windows 10 for 32-bit SystemsWindows 10 for x64-based SystemsWindows 10 Version 1607 for 32-bit SystemsWindows 10 Version 1607 for x64-based SystemsWindows 10 Version 1703 for 32-bit SystemsWindows 10 Version 1703 for x64-based SystemsWindows 10 Version 1709 for 32-bit SystemsWindows 10 Version 1709 for ARM64-based SystemsWindows 10 Version 1709 for x64-based SystemsWindows 10 Version 1803 for 32-bit SystemsWindows 10 Version 1803 for ARM64-based SystemsWindows 10 Version 1803 for x64-based SystemsWindows 10 Version 1809 for 32-bit SystemsWindows 10 Version 1809 for ARM64-based SystemsWindows 10 Version 1809 for x64-based SystemsWindows 10 Version 1903 For 32-bit SystemsWindows 10 Version 1903 for ARM64-based SystemsWindows 10 Version 1903 for x64-based SystemsWindows 7 for 32-bit Systems Service Pack 1Windows 7 for x64-based Systems Service Pack 1Windows 8.1 for x64-based systemsWindows RT 8.1Windows Server 2008 for 32-bit Systems Service Pack 2Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) Windows Server 2008 for Itanium-Based Systems Service Pack 2Windows Server 2008 for x64-based Systems Service Pack 2Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1Windows Server 2008 R2 for x64-based Systems Service Pack 1Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) Windows Server 2012Windows Server 2012 (Server Core installation) Windows Server 2012 R2Windows Server 2012 R2 (Server Core installation) Windows Server 2016Windows Server 2016 (Server Core installation) Windows Server 2019Windows Server 2019 (Server Core installation) Windows Server Version 1803 (Server Core Installation) Windows Server, version 1903 (Server Core installation) repair recommendation

1. As the poc for this vulnerability has been publicly circulated on the Internet, it is strongly recommended that users install Microsoft's security update patch for this vulnerability in time:

Https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040

two。 Other mitigation measures

The following measures can be used as a temporary solution when security update patches cannot be installed in a timely manner. In order to ensure security, it is still recommended that the majority of users install the patches in time if conditions permit:

1) enable mandatory SMB signature for all servers in the domain (in Windows domain, only domain control servers enable forced SMB signature by default)

2) enforce LDAP signature and LDAP channel binding on LDAP over TLS to prevent NTLM from relaying to LDAP

3) enable EPA to force all Web servers (OWA,ADFS) to accept only EPA requests

4) Open the Channel Binding of related applications on all important servers (such as all Exchange servers)

5) reduce use of NTLM

6) disable Printer Spooler service if there is no special need

This is the answer to the question on how to analyze Windows NTLM tampering vulnerabilities. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.