Hijacking a Domain Controller with Netlogon RPC aka Zerologon: CVE-2020-1472
On September 14th, researchers at security firm Secura published a white paper detailing a complete unauthenticated compromise of domain controllers by subverting the Netlogon cryptography. The vulnerability, dubbed “Zerologon” (CVE-2020-1472) is a privilege escalation bug with a CVSSv3 score of 10.0 and allows a remote attacker to establish a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC) and take over Windows Servers running as Domain Controllers.
Vulnerability Details and Analysis
MS-NRPC is an RPC interface that is used exclusively by domain-joined devices. It includes an authentication method and a method of establishing a Netlogon secure channel. The vulnerability uses a weak cryptographic algorithm in Netlogon’s authentication process to allow full takeover of Active Directory domains. The flaw lies in Netlogon’s cryptographic implementation of AES-CFB8 encryption. An attacker can impersonate a DC account and replace it with all zeros. As per Secura’s white paper, for 1 in 256 keys, applying AES-CFB8 encryption to an all-zero plaintext will result in an all-zero ciphertext. By sending a number of Netlogon messages in which various fields are filled with zeroes, an attacker can change the computer password of the domain controller.
Exploitation
Below are screenshots explaining the exploitation details listed in the white paper.
- Bypassing the authentication call
The client is authenticating itself by doing NetrServerAuthenticate3 call after the exchange of the challenges. This call has a parameter called ClientCredential, that was computed during the client challenge. Since the client challenge can be set to zeroes, it means that for 1 in 256 session keys, the correct ClientCredential will consist of 8 zeroes. With several tries, the correct key will be hit in an average of 256 tries, but in implementation it only takes a few seconds.
Figure 1: Packet capture with several authentication attempts until response is not DENIED
- Disabling RPC signing and sealing
Even if the authentication call is bypassed, the real value of the session key would be unknown. Since Netlogon's transport encryption’s use of this key is optional, the client can disable the mechanism in the flag of the NetrServerAuthenticate3 call.
Figure 2: Disable signing and sealing flag used in the POC code (Source: https://github.com/dirkjanm/CVE-2020-1472)
Figure 3: NetrServerAuthenticate3 packet with the flag set
- Computing the Authenticator value
Every call must contain an authenticator value which is computed by applying ComputeNetlogonCredential (with the session key) to the value ClientStoredCredential + Timestamp. The ClientStoredCredential is incrementing value starting from zero since client credential consists of zeroes. While the timestamp contains current Posix time, the server does not place any restriction on this value, and it can be set to zero.
- Changing computer's AD Password
Using the NetrServerPasswordSet2 call, a new password for the client can be encrypted with the session key using the AES-CFB8. Netlogon plaintext password consists of 516 bytes, the last four indicate the password length. By providing 516 zeroes, this will be decrypted to 516 zeros or an empty password. Changing the password this way only updates it in the AD.
Figure 4: NetrServerPasswordSet2 request packet with empty password (516 zeroes)
- Changing Domain Admin Password
Using the previous steps to change the password of the domain controller, the DC password was changed in the AD, but not in the local registry. This only works when DC validates a login attempt with the password stored in AD. It was found that using Impacket's secretdump, the newly set DC password can be used to compromise the system.
Let’s look at the proof of concept in action.
Proof of Concept
Secura released a Python script to test the presence of the vulnerability. Multiple other PoCs are available on Github, all based on the Secura proof of concept. See 1, 2, 3, 4.
Figure 5: Exploitation of the Vulnerability using: https://github.com/dirkjanm/CVE-2020-1472
Figure 6: Using john the ripper to crack the nthash
After using the PoC code, nthash of the DC changed to 31d6cfe0d16ae931b73c59d7e0c089c0 which is an empty password when decrypted.
Impact
This is a very high impact and a severe vulnerability allowing a local attacker to completely compromise the Windows domain. Exploitation by advanced threat actors is highly possible and this vulnerability offers ransomware groups to attack organizations with network-accessible hosts.
How to protect your systems?
Microsoft is addressing the vulnerability in a phased two-part rollout. The initial phase started with the August 11th, 2020 Patch Tuesday update. Customers who have applied August 2020 Patch Tuesday Security updates are protected against Zerologon attacks. The patch fixes the problem by enforcing the Secure Netlogon Remote Protocol for all Windows servers and clients in the domain. We urge organizations that have not applied the August 2020 Patch Tuesday updates, to patch CVE-2020-1472 immediately. Phase 2, planned for the first quarter of 20201, will be an enforcement phase. Microsoft has also provided guidance on deploying Domain Controller enforcement mode at https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc#EnforcementMode.
Detection Guidance
Trustwave’s Security Testing Services customers can detect this vulnerability via authenticated scans.
References
https://www.secura.com/pathtoimg.php?id=2055
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472
https://us-cert.cisa.gov/ncas/current-activity/2020/09/14/exploit-netlogon-remote-protocol-vulnerability-cve-2020-1472