Introduction
CVE-2020-1472, also known as “Zerologon”, is a critical vulnerability that allows an unauthenticated attacker to gain domain administrator access to any given, vulnerable Domain Controller (also referred to as “DC”). This is due to the incorrect use of an AES mode of operation, which allows anyone to spoof the identity of any computer account and set an empty password for that account in the domain. This vulnerability is rated with the highest possible CVSS score of 10.0 (critical). This is mainly because all versions of the Windows Server Netlogon Remote Protocol are affected, while the setup phase for the attack remains straight-forward. The only thing an attacker needs is the ability to set up a TCP connection with a vulnerable DC.
Presenting the Netlogon protocol
To understand the Zerologon attack we first need to obtain an understanding of the underlying Netlogon Remote Protocol.
What is the Netlogon protocol used for?
The Netlogon Protocol is used for tasks related to machine and user authentication. Further capabilities include authentication of NTP (Network Time Protocol) responses as well as letting a computer update its password in a domain. This last point is of particular interest to any attacker seeking to compromise a user or even a complete domain.
Understanding the Netlogon Handshake
Figure 1 shows a simplified Netlogon authentication handshake. The client initiates the handshake by sending an 8-byte arbitrary value, the ClientChallenge. The server saves the ClientChallenge and responds with his own value, the ServerChallenge. In protocol design language these two challenge-values are also referred to as “nonces”. The session key can now be derived by both parties through the designated key derivation function (KDF).
The client then proceeds to use this freshly generated session key to generate the ClientCredential. The server verifies the client's possession of the session key by recomputing the Client Credential. On the server’s side, if these two values match, the server can be assured that the client is in possession of the session key and, thus, must also know the computer password. To achieve mutual authentication, the server goes on to generate the ServerCredential, which is then verified by the client. During the authentication handshake, both parties can negotiate whether they want to encrypt and/or sign any subsequent messages, which is essential to protect against network-level attacks.
What causes the vulnerability?
Looking at Figure 1, there is no obvious flaw to be observed at first sight. To uncover the vulnerability’s root cause, we have to dive a little bit deeper.
The source for CVE-2020-1472 lies in the creation of the Client- and ServerCredential values; the ComputeNetlogonCredential Function. This computation process is realized through a weakly implemented cryptographic function, AES-CFB8. Most people should be familiar with the Advanced Encryption Standard (AES) by now. For years, it has been the industry standard for encryption. The second part of the naming convention, CFB8, stands for 8-Bit Cipher Feedback Mode, a mode of operation that determines how a block cipher handles the computation and assembly of multiple computed blocks into the final ciphertext. This plays a role when the input for the block cipher is greater than its designated block size.
A key principle for creating a secure cryptographic protocol states: If an operation mode for a block cipher uses an Initialization Vector (IV), this value should be generated randomly and Figure 1: Simplified Netlogon authentication handshake Leo Duntze Intern SOC Analyst L1 Senthorus most importantly, deleted after each session, such that no subsequent sessions use the same IV. The Netlogon implementation of the AES-CFB8 defines that this IV is fixed and should always consist of 16 zero bytes. This violates the requirements on how to use AES-CFB8 securely since the security properties of AES CFB8 only hold when the IV is chosen completely random. The resulting consequences are shocking: there is on average a 1 in 256 chance that any given all-zero input results in an all-zero output.
This means that an attacker can brute force this authentication scheme by sending authentication packets containing all-zeros. Eventually he will hit the all-zero iteration in the AES-CFB8 scheme, allowing him to succeed with his authentication. Figure 2 shows the special iteration in the AES-CFB8 scheme:
How does the exploitation work?
We now have the necessary understanding to continue with the detailed explanation of the attack-stages.
Step 1: Initiation
The attacker initiates a Netlogon authentication request by sending a specially crafted Netlogon message to the domain controller.
Step 2: Malicious Netlogon Messages
The attacker sends a series of malicious Netlogon messages with empty plaintext fields, using the AES-CFB8 encryption mode. The attacker needs around 256 authentication messages before succeeding. This should take around 3 minutes in practice. As seen before the implementation lacks a good Initialization Vector and hence allows the attacker to effectively calculate the resulting ciphertext without needing the AES key.
Step 3: Authentication Bypass
By sending these manipulated messages, the attacker tricks the authentication process into believing that the provided plaintext is legitimate and should be encrypted with the same key. This leads to the encryption of an empty plaintext, which results in an all-zero ciphertext. The domain controller incorrectly validates this ciphertext as legitimate, allowing the attacker to impersonate the domain controller. Figure 4 shows a Packet Capture (PCAP) of such a successful attack.
Step 4: Change a Computer’s AD Password
The attacker now impersonates the domain controller, he can use Netlogon to change the computer password of the targeted domain controller to an empty value, effectively neutralizing the security barrier.
Step 5: Privilege Escalation
With the domain controllers computer password set to an empty value, the attacker can establish a secure channel to the domain controller without providing valid credentials. This can lead to unauthorized administrative access to the domain, privilege escalation, and potential network-wide compromise.
Impact
Zerologon has severe consequences. Such as:
- Complete Domain Compromise: An attacker can compromise the entire Active Directory domain, which includes unauthorized access to critical resources and sensitive information.
- Privilege Escalation to Domain Administrator: With control over a domain controller the attacker can gain access to higher privileged systems/ accounts in the network.
- Spread of Malware: Controlling an entire domain allows the attacker to spread malware across systems or even the entire network.
Defending against Zerologon?
How to mitigate the vulnerability?
Microsoft released a patch in their August 2020 security update. Applying the patch is the most important step to mitigate the risks posed by CVE-2020-1472. Further, the following actions are recommended:
- Enforce secure RPC (Remote Procedure Call) communication.
- Monitor network traffic for suspicious activity related to Netlogon.
- Consider using enhanced security features like Microsoft’s “Domain Controller Enforcement Mode” to enhance Netlogon security.
Artifacts to be observed
The exploit leaves behind various artifacts that can be used for detection. The most documented one is Windows Event ID 4742 “A computer account was changed”, often combined with Windows Event ID 4672 “Special privileges assigned to new logon”. Even though Event 4742 is uncommon, it happens periodically, so when creating detection rules, you should be aware that this will create False Positive detections. The problem with Event ID 4672 is that it is not a necessary part of the original exploit, it rather covers the privilege escalation process.
Since both Event IDs do not allow for a 100% safe identification of an attack, it is best to monitor your network for unusual network traffic spikes.
How can I check if You are vulnerable?
If you want to ensure that your systems are not vulnerable to the Zerologon attack, you can quickly make use of a test-tool that was published by Secura from their GitHub repository at: https://github.com/SecuraBV/CVE-2020-1472.
Summary
CVE-2020-1472 or better known as Zerologon, had many security experts on their toes, mainly because of the high number of networks that were exposed to the vulnerability and the severe consequences an attack has on a domain. A successful execution allows an attacker to compromise an entire domain with little effort.
The only prerequisite is a TCP connection to a vulnerable domain controller, which means that basically any person with access to the local network, can carry out such an impactful attack.
This is one of the reasons why Zerologon received the highest possible CVSS-score of 10.0.
We have once again seen that - as so often within the Security domain - small implementation errors can make, or completely break the security of a solution. And thus, it’s more important than ever to constantly remain up-to-date as well as patching vulnerable systems on time.
