Zerologon: Critical Vulnerability of Windows AD

10/20/2020

The name of the vulnerability is closely related to the main attack vector exploiting the vulnerability, which is a bug in the configuration of the initialisation vector (IV) when encrypting Netlogon Remote Protocol (MS-NRPC) messages, allowing an internal attacker to fully break the encryption and to pass off as any computer of his choice in the network.

The impact of this vulnerability is enormous. So troubling in fact, that its severity in the Common Vulnerability Scoring System (CVSS) reached a critical 10 out of 10. A successful exploitation of the vulnerability allows an attacker who can establish TCP connections to a Domain Controller to escalate his privileges all the way up to the level of the domain admin, resulting in a complete compromising of the entire domain as well as all the systems connected to it. In most cases (unless the domain controller is publicly available from the Internet), the attack can only be performed from the internal network, therefore the chances of its misuse are reduced.

There are several scripts already circling on the Internet nowadays exploiting the vulnerability successfully (mostly to evidence the concept); also, due to the data available from some honeypot systems (systems that are intentionally vulnerable and accessible from the Internet, for which any attempts of exploit are actively monitored), the vulnerability is already actively and automatically exploited by several hacker groups on a global scale.

Microsoft announced two patches fixing the defect allowing this vulnerability. The first patch was issued on August 11, 2020 and it was labelled as critical. This patch fixes the bug enabling the attack and making it possible for an attacker to authenticate himself as any machine in AD. It should present a sufficient way of preventing the exploit. For this reason, we strongly recommend you to apply the patch and to update all domain controllers as soon as possible.

The second patch is planned for the beginning of the upcoming year and deals with one of the mechanisms of the RPC protocol related to the Signing and Sealing of RPC messages (RPC Signing and Sealing). This feature, set by a flag in the header of every message, determines whether the communication between the client and the DC is encrypted. By simply setting the value to 0, an attacker can turn this mechanism off and now he can send any messages without knowing the actual encryption key. This patch is not critical for the prevention of the vulnerability, since in order to be exploited, an authentication to the domain controller is required, which has been prevented by the first patch.

Technical details

The vulnerability was announced in a report published in September 2020 by Tom Tervoort, a security researcher representing Secura. The report describes the flaws in the implementation of Netlogon Remote Protocol (MS-NRPC) encryption and the way in which it is possible to establish an authentication to a domain controller for any machine in the network, including the domain controller itself, with a simple brute force attack.

The MS-NRPC protocol is used in the AD environment for tasks related to the authentication of user and machine accounts. Most often, it is a matter of logging in to servers using the NTLM protocol, as well as changing the user password in the domain for example.

There is one thing peculiar about this protocol. And this is the fact that it does not use standard domain authentication mechanisms, such as Kerberos, but uses a different procedure instead. Simply put, for an authentication to be successful, the client and the server will exchange a set of random numbers (challenges) which they will combine with the user password hash, resulting in a common encryption key. Once the key generated by the client is identical to the key generated by the server, it is taken as a proof that the client knows the user's password and therefore, that it can be authenticated.

The issue lies in the manner in which the encryption key proving that the client knows its password is created. An AES[ZN1] encryption is used to produce the key, but in a relatively obscure setting know as CFB-8, and in addition to it, also used in a wrong way, because it contains an initialisation vector with fixed value of 16 bytes of zeros (the initialisation vector is one of the primary mechanisms providing the proper functioning of this type of encryption, and it should be always a random number). Research has shown that this bug results in the fact that with the zero IV and for a randomly selected encryption key, the data containing only zeros will be encrypted as all zeros in one of about 256 cases (see the figure below).

The Zerologon vulnerability relies on this feature and bypasses the calculation of the client challenge required by the server to prove that the client knows the correct value of the encryption key calculated for this session. The value required by the server is calculated by encrypting the selected random number (which is chosen by the client in the previous authentication step) with an encryption key generated on the basis of both random numbers (from the client and the server). Therefore, due to the encryption flaw described above, it is possible to forge this answer, since in case the client selects its random key in the form of all zeros, the encrypted value will equal a chain of all zeros for 1 out of 256 encryption keys on average. Thus, it is sufficient for an attacker to repeat the log-in process approximately 256 times until this phenomenon occurs, resulting in a successful authentication and gaining the ability to perform actions on the user account, such as changing the password.

In order to complete the attack successfully, it is necessary to exploit the second part of the vulnerability connected to RPC Signing and Sealing of messages. This feature determines whether the rest of the communication between the server and the client will be encrypted (using the encryption key obtained in the previous step), or if the communication will be unencrypted. However, the authentication handshake includes a header defined by the client allowing this feature to be disabled, thus enabling the attacker (not knowing the encryption key because the log in as such was executed with no knowledge of it by exploiting the first part of the Zerologon vulnerability) to send additional requests to the server without restriction and to continue doing so until the server is completely compromised by changing the password for the domain administrator.

Patching the vulnerability

To prevent the exploitation of the vulnerability, application of security patches to all Windows Servers version 2008 and later is required, according to the information available at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472.

Sources

Mikuláš Hrdlička
Cyber Security Specialist
AEC a.s.