Taking over Windows systems with a Netlogon man-in-the-middle attack (CVE-2019-1424)
Blog post 15 November 2019, by Tom Tervoort, Senior Security Specialist at Secura
On November 2019 Patch Tuesday, Microsoft released a fix for CVE-2019-1424, a Netlogon Security Feature Bypass Vulnerability. This is a serious flaw I accidentally discovered, which allows attackers to gain remote local administrator access to a domain-joined Windows machine, if they can intercept and alter that machine’s network traffic (by obtaining a Man-in-the-Middle position for instance).
The Netlogon Remote Procotol is Remote Procedure Call (RPC) protocol that performs various functions on Windows networks related to Active Directory authentication. It can be used, for example, to reset machine passwords or to back up the domain controller’s user database. The most common application, however, is to facilitate remote logins though the NTLM protocol.
The purpose of the NTLM protocol is to allow domain users to log in to remote systems within the network, such as servers providing file shares or intranet websites. While this protocol has been superseded by Kerberos since the introduction of Windows 2000, it is still widely used and supported. Almost all Windows services supporting Kerberos authentication will by default also allow clients to log in using NTLM.
When someone successfully authenticates to a Windows domain, an MD4 hash (also called an “NTLM hash”) of their password is computed.1 The domain controller also stores MD4 hashes of all users’ passwords. When the client then wants to authenticate to a service using NTLM, that service will transmit a random challenge to the client. In order to prove the user’s identity, the client will respond with a cryptographic MAC (Message Authentication Code), computed over the challenge using the user’s password hash as a secret key.
When the service in question is not running on the domain controller itself, it does not actually have access to the password hash and therefore cannot validate whether the MAC is correct. In that case, the system running the service will establish a connection with the domain controller and send it the challenge along with the response received from the client. The domain controller will verify the MAC, and inform the service whether or not it is valid. If not, that might mean a user has entered the wrong password. If authentication succeeds however, the domain controller will also inform the service what groups the user belongs to, and provide it with a secret session key.2 This information exchange between the machine running the service and the domain controller makes use of the Netlogon Remote Protocol.
Illustration 1: Normal operation of the NTLM authentication protocol (happy flow). The connection between the server and DC uses the Netlogon protocol
The Netlogon Remote Protocol is built on top of MSRPC (Microsoft Remote Procedure Call), and its specification is publicly available. When a client wants to establish a Netlogon connection with the domain controller, it first connects to the EPM (Endpoint Mapper) service on TCP port 135. The domain controller will then inform the client at which TCP port a Netlogon service is available. If the client can’t reach the EPM service or the indicated port (possibly because a firewall blocks it), it will instead tunnel a Netlogon connection over the SMB protocol on port 445. This means Netlogon calls are either transmitted using MSRPC-over-TCP or MSRPC-over-SMB-over-TCP.
Because the integrity and confidentiality of the information exchanged via the protocol is critical, cryptographic controls are used to protect remote procedure calls and their answers. Interestingly, Netlogon does not use standard MSRPC encryption, but an alternative protocol. At the start of a connection, the client and server exchange random values and then derive a session key from a combination of the client’s machine password and these two values. The client then authenticates by proving possession of this session key. All subsequent packets are encrypted and authenticated using the session key. This process is identical regardless of whether the SMB tunnel is used.
Because the cryptographic protocol used for Netlogon is rather unorthodox and has not been put under much scrutiny to my knowledge, I decided to investigate possible vulnerabilities in the protocol or its implementation. While testing a lab setup in which I would be capable of performing man-in-the-middle attacks against the protocol, I suddenly noticed something strange in my network capture: Netlogon calls that were not being encrypted.
After some experimentation, I discovered that this was caused by me accidentally blocking traffic to both EPM and the dynamic Netlogon port, causing a fallback to SMB. Normally, this would not be an issue: if EPM is not available the client would perform the authentication handshake as normal and start encrypting messages afterwards. In this case, however, I blocked traffic to these ports after an encrypted session had already been established.
For some reason, when a fallback to SMB takes place while a session has already been established, subsequent Netlogon packets are not encrypted and their integrity is not protected. Server and client messages would still contain “authenticators”, however, which are mandatory message fields that are generated with the session key. These values do not depend on the content of the rest of the message though, so an attacker could make any arbitrary changes to messages, as long as they simply left the original authenticator in place.
An attacker with a man-in-the-middle position between the machine and the domain controller could therefore force encryption to be disabled by triggering the SMB fallback right after the machine performed the authentication handshake. This could be accomplished by injecting TCP RST packets when the client attempts to connect to port 135 or to the dynamic Netlogon port.
An attacker capable of spoofing Netlogon responses from the domain controller to a machine would then be able to use this attack to replace a “login failed” response with a “login succeeded” message. This message would be honored by the machine, thinking the DC had successfully authenticated the user. They would also be able to determine what groups the user trying to log in would belong to.
Illustration 2: Man-in-the-middle attack: attacker undoes encryption and spoofs a Netlogon response in order to give themselves administrator access to the target.
It would not be necessary to wait for some other user to attempt to log in. Instead, the attacker can login themselves, pretending to only support NTLM and providing some invalid password. The service they are logging in to will forward the NTLM handshake to the domain controller and the domain controller would reply with a negative response. This message could then be replaced by a spoofed reply (also containing a recalculated session key) indicating that the password was correct and, by the way, the user trying to log in happened to be a member of the domain admin group (meaning they also have administrative privileges on the target machine).
When a man-in-the-middle position is obtained between some system X and the domain controller, an attacker will be able to use this attack to log in as an administrator to any service on X that supports NTLM authentication. Through various types of services, like SMB, WMI or DCOM, the ability to log in as an administrator can lead to remote code execution with that role, meaning that the targeted system can be compromised completely.
Targets against which this attack is likely to succeed are people’s workstations, which often allow incoming SMB connections. Additionally, there are many techniques an attacker can use to carry out man-in-the-middle attacks against those systems: such as ARP/NDP spoofing, DHCP response spoofing, setting up a malicious Wi-Fi access point, or plugging an interception device into a network socket.
This vulnerability can be particularly dangerous when an attacker has a foothold in an internal network because it allows for both elevation of privileges (to local admin) and lateral movement (gaining RCE on other machines on the network).
After disclosing this vulnerability and a working Proof-of-Concept exploit chain to Microsoft, they responded quickly, and a fix was released on November 12, 2019. It is strongly advisable that this patch is applied (at least to domain controllers) as soon as soon as possible, as this is will completely mitigate this vulnerability.
- When doing passwordless authentication with smartcards or Windows Hello, the domain controller will instead provide the client with an MD4 hash of a long randomly generated password. This mitigates a major flaw in the NTLM protocol, which pentesters and attackers love to take advantage of: its vulnerability to offline password guessing attacks.
- This key is derived from the password and can independently computed by the client. Several protocols, including SMBv3, make use of this shared secret to authenticate and encrypt traffic between the client and server.
- Pulse connect secure sve 2019 11510 by Matthijs Koot, October 2019 (in Dutch)
- Multiple vulnerabilities affecting various Solar Inverter Kits by Jos Wetzels, September 2019
If you're interested in more content like this, make sure to sign up for Secura's periodical newsletter.