The talk
========
In this talk I would explain an attack I discovered against the Netlogon Remote Protocol (CVE-2019-1424; patched by Microsoft in November 2019), which allows a man-in-the-middle attacker to log in as any (local administrator) user to a domain-joined Windows system. This means that once an attacker can intercept and modify traffic between a Windows system and a domain controller (for example after ARP spoofing, setting up a malicious WiFi access point or stealing a laptop using Bitlocker in TPM Only mode), can use a simple and reliable exploit to gain privileged remote code execution.
Before diving into the details of this attack, the talk would first cover the details of Netlogon and its relation to NTLM; prior work that abuses Netlogon to enable NTLM relay attacks (CVE-2015-005, CVE-2019-1019); as well as the obscure custom cryptographic schemed used by the protocol to authenticate users and protect messages.
Attack details
==============
Background
———-
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 NTLM 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. The domain controller also stores MD4 hashes of all user 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. This information exchange between the machine running the service and the domain controller makes use of the Netlogon Remote Protocol.
The 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.
The vulnerability
—————–
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 leave 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.
Impact
——
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 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.
