Zerologon- CVE-2020-1472

Summary:

On August 11^th Microsoft published a security advisory for the critical vulnerability CVE-2020-1472, dubbed “Zerologon”. The vulnerability was discovered by security researchers at Secura who published a whitepaper with their findings, which can be found here.

This vulnerability affects all versions of Windows and allows an attacker on the network to escalate to domain administrator privileges, if exploited. This is done by exploiting an insecure implementation of AES cryptography in Microsoft’s Netlogon protocol. Ultimately allowing the attacker to spoof the identity of any domain joined computer.

The only requirement for an attacker to successfully exploit a vulnerable domain controller is that they can establish a TCP connection to the vulnerable domain controller. No credentials are needed to exploit this vulnerability.

Technical Details:

As previously stated, the vulnerability is present in Microsoft’s Netlogon Remote Protocol (MS-NRPC). The vulnerability stems from an insecure implementation of AES cryptography, particularly the AES-CFB8 (8-bit cipher feedback) mode.

AES typically requires 16 bytes of input and encrypts that into 16 bytes of cipher code. However, according to Secura, MS-NRPC, particularly the “ComputeNetlogonCredential” function, encrypts an 8-byte input and a key to produce an 8-byte output of ciphertext. This is done using the AES-CFB8 mode.

The way that this encryption normally works is by encrypting one byte at a time. First, a random 16-byte Initialization Vector (IV) is prepended to the plaintext message to be encrypted. Second, the first 16-bytes of the message are encrypted using AES and the provided key. Third, an XOR operation is done on the first byte of the AES result and the first byte of the plaintext message. This result is the first byte of ciphertext. Following this, the first byte of the IV is discarded and the first byte of cipher text is appended to the next 16-bytes to be encrypted using AES. This process is continued until the entire 8-byte message is encrypted, at which point the remaining IV is discarded and the only information remaining is the 8-byte ciphertext.

Image Source: Secura Whitepaper

As discovered by Secura, the problem with Microsoft’s implementation of this, comes from the fact that the “ComputeNetlogonCredential” function does not randomly generate an IV each time a new message needs to be encrypted, in fact the IV value is statically set to be 16 zero bytes. As a result, when an 8-byte message of all zero bytes is run through this AES encryption, there is a 1 in 256 chance that the first byte of the output will be a zero byte. From there, when you run an XOR operation on both the first byte of the AES encryption and the first byte of the 8-byte message you get a zero. Therefor, given enough attempts, you will eventually end up with 8 bytes of cipher text that is all zeros, the same as the initial message.

Image Source: Secura Whitepaper

Its because of this behavior that an attacker can spoof the identify of any of the domain joined computers. Even without knowing the shared secret between the client and server, an attacker can create valid session tokens.

Once the attacker has a valid session token, they can make other MS-NRPC calls. Through repeat exploitation of the “ComputeNetlogonCredential” function, the attacker can change the computer account’s password, taking over the computer account entirely. This becomes dangerous as the attacker can take over the domain controller’s computer account with this method. While the attacker will only be able to make MS-NRPC calls that validate the credentials stored in AD, this does open up the ability for the attacker to extract all user hashes using the Domain Replication Service. Among these hashes would be the “krbtgt” key, which would allow the attacker to issue golden tickets. At this point, the attacker has effectively gained domain administrator privileges and has full control of the domain.

Indicators:

There are few things that could potentially be signs of an active attack.

• Several unsuccessful MS-NRPC authentications for computer accounts followed by a successful one.
• A computer account changes their own password, following multiple MS-NRPC authentication failures.
• Once a computer account’s password is changed, there are multiple MS-NRPC authentication failures from another source on the network. This is a sign that previous authentications could have been spoofed.
• Domain controller is exhibiting strange and unpredictable behavior due to the AD password for the DC being different that the local password in the registry. This is a result of an attacker spoofing the DC’s computer account and changing the DC’s computer account password for AD.

Detection:

There are several tools that can be used to detect whether a DC is vulnerable to Zerologon.

Industry standard vulnerability scanner, such as OpenVAS/Greenbone Vulnerability Manager (GVM), can detect this vulnerability by conducting an authenticated scan. Through our testing, it does not appear that OpenVAS/GVM, are currently capable of detecting this vulnerability through an unauthenticated scan.

As of September 14^th, Proofpoint has published signatures in their open feed to detect Zerologon attacks. The Suricata signatures are as follows:

• alert tcp any any -> [$HTTP_SERVERS,$HOME_NET] any (msg:”ET EXPLOIT Possible Zerologon NetrServerReqChallenge with 0x00 Client Challenge (CVE-2020-1472)”; flow:established,to_server; content:”|00|”; offset:2; content:”|04 00|”; distance:19; within:2; content:”|5c 00 5c 00|”; within:50; content:”|00 00 00 00 00 00 00 00|”; isdataat:!1,relative; fast_pattern; threshold: type limit, count 5, seconds 30, track by_src; reference:url,www.secura.com/blog/zero-logon; reference:cve,2020-1472; classtype:attempted-admin; sid:2030870; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Server, created_at 2020_09_14, cve CVE_2020_1472, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, updated_at 2020_09_14;)
• alert tcp any any -> [$HTTP_SERVERS,$HOME_NET] any (msg:”ET EXPLOIT Possible Zerologon NetrServerAuthenticate with 0x00 Client Credentials (CVE-2020-1472)”; flow:established,to_server; content:”|00|”; offset:2; content:”|1a 00|”; distance:19; within:2; content:”|5c 00 5c 00|”; within:50; content:”|24 00 00 00 06 00|”; distance:0; fast_pattern; content:”|00 00 00 00 00 00 00 00|”; distance:0; isdataat:!5,relative; threshold: type limit, count 5, seconds 30, track by_src; reference:url,www.secura.com/blog/zero-logon; reference:cve,2020-1472; classtype:attempted-admin; sid:2030871; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Server, created_at 2020_09_14, cve CVE_2020_1472, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, updated_at 2020_09_14;)

Additionally, security researchers at Secura have published a Python script that can be run against DCs to determine whether it is vulnerable. The script is available on their GitHub here.

Prevention:

The best prevention is to install the patch published by Microsoft, for the appropriate OS. The patches can be found on Microsoft’s Security Advisory portal here. The patch makes a few underlying changes to the MS-NRPC protocol which are outlined here.