Zerologon is a Big Deal. Here’s Why.

Every once in a while a vulnerability comes along that is so serious and so widespread that it warrants immediate attention. The Zerologon vulnerability uncovered by the firm Secura and patched by Microsoft in CVE-2020-1472 last month is one of those.  How bad is it? The Department of Homeland Security over the weekend essentially issued an emergency order to federal agencies to patch Zerologon by the end of the day Monday.

So, first thing first: if you haven't already applied Microsoft's patch, do so. Now!

Now that you've done that, we can talk about what Zerologon is, why it's so dangerous and what it means for your larger security program.

It’s also worth noting what other security issues, including domain dominance attacks, rhyme with Zerologon.

What is Zero Logon?

Zero Logon is a critical vulnerability that was discovered in the Netlogon Remote Protocol, an RPC interface that serves a variety of purposes. Generally speaking, Netlogon is used for user and machine authentication to servers on domain-based networks using the NTLM protocol. It is also used to facilitate password updates for computers on a particular domain, among other functions.

According to a Security Advisory issued by QOMPLX to its customers, Zerologon is an enterprise level threat and affects all Domain Controllers (DCs) and Read-Only Domain Controllers (RDOCs).

Zerologon is an unauthenticated threat - meaning attackers need not have compromised account credentials to carry it out, though they do need to have obtained access to a target environment. (Meaning: it is not a remote attack risk.)

With Zerologon, an attacker could impersonate the identity of any computer on the network when trying to authenticate against the domain controller, disable security features in the Netlogon authentication process, change a computer's password on the domain controller's Active Directory and—eventually—generate "Golden Ticket" and other Active Directory and Kerberos forgeries that would give them the ‘keys to the kingdom.’

How does Zerologon work?

According to research published by Tom Tervoort of the Dutch security firm Secura, a flaw in the Netlogon protocol allows anyone with access to a system to forge an authentication token for Netlogon functionality that then allows them to set their own password of any computer on the domain, up to and including the Domain Controller.

Specifically: Tervoort discovered a whopper of a design flaw in a critical function used to create cryptographic primitives that both client and server need to authenticate. That function, ComputeNetlogonCredential,  manages an AES block cipher operation that takes an input of 16 bytes and permutes it to a 16 byte output.

In analyzing ComputeNetlogonCredential, Tervoort found that the function relies on a rather obscure AES mode of operation known as CFB8 to encrypt each byte of the plaintext. It works by prepending a 16-byte ‘Initialization Vector’ to the plaintext, then applying AES to the first 16 bytes of the IV+plaintext, taking the first byte of the AES output, and XOR’ing it with the next plaintext byte.

The problem is: to bootstrap this encryption process with a new text value, an Initialization Vector (IV) must be provided by the encryption process itself. And, this being encryption, the IV value should be random and unique for each chunk of plaintext that is encrypted. As written, however, the ComputeNetlogonCredential function always uses the same, fixed IV to bootstrap the process: 16 zero bytes ("0000000000000000"). Obviously, without a random and unique IV value, the security of AESCFB8 unravels.

How? Well, with an all-zero input as the IV, Tervoort discovered that for one in every 256 keys, applying the AESCFB8 encryption to an all-zero plaintext will result in an all-zero ciphertext.

This opens a simple avenue of attack. Any adversary with network access can spoof a client credential, first by exchanging challenges with a NetrServerReqChallengecall, then authenticating by issuing a NetrServerAuthenticate3 call, which has a ClientCredential parameter that is generated  by applying the ComputeNetlogonCredential to the client challenge that was sent in the previous call. Based on our knowledge of the flaw in how ComputeNetlogonCredential calculates the credential, we know that by setting the client challenge value to 8 zeroes, 1 in every 256 returned session keys will have a value of 8 zeroes ("00000000"), as well.

Of course, an attacker can't know that a given session actually uses an all-zeros session key. But she does know that the server will generate a unique server challenge for each authentication session, and that the challenge is a parameter of the session key derivation for each logon attempt. So she need only try to logon 256 times to successfully authenticate - a process that takes all of three seconds, according to Tervoort, who adds that computer accounts generally do not lock after a set number of failed authentication attempts, making the brute force attack possible.

From Spoofed Credential to Domain Admin

This isn't the end of the line. Tervoort's analysis shows how an attacker would move from spoofing that initial client credential to changing the computer's Active Directory password by exploiting another NTLM function, NetrServerPasswordSet2 which, also, relies on the AESCFB8.

Passwords in the Netlogon protocol consist of 516 bytes, with the final four bytes indicating the password length (in bytes). That part is key. Because, by simply providing a password consisting of 516 zeroes an attacker guarantees that it will be decrypted as 516 zeroes – including those last four bytes. In other words: a "zero-length" password. (Setting empty passwords for a computer is allowed with NTLM.)

With a known (empty) password, an attacker can initiate a new Netlogon connection with the target system and then set a new password of their choosing. The attacks work not just for client machines, he notes, but for domain controllers as well.

The Big Picture: More AD Security, Less NTLM

From a security standpoint, Zerologon is a serious concern. Even the NSA is drawing attention to the need for immediate patching and noting expected exploitation. QOMPLX advises its customers to install Microsoft’s August 2020 security patches on all Active Directory domain controllers, to include RODCs, as soon as possible. Installing the August 2020 patch on all domain controllers will be sufficient to block the high-impact exploit described for all Windows devices. Protection for all remaining domain-joined non-Windows devices will still have to be enforced. Microsoft states the required fix has been included in last month’s (August 11, 2020) Patch Tuesday release. (Read Microsoft's bulletin "How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472")

The bigger fix is for organizations to pay closer attention to what's happening within their Active Directory environment, and to stop using NTLM altogether. Microsoft long ago supplemented NTLM with its version of the more secure Kerberos authentication protocol making "Pass the Hash" attacks impossible. The company has been urging customers to reduce their use of, or abandon, NTLM for Kerberos ever since. Twenty years later, however, NTLM use is still common.

QOMPLX believes that the biggest single step organizations can take to limit the spread of ransomware within their environments is to work towards turning off NTLM authentication. Full. Stop. That's strong medicine. It will take time. But CISOs and other senior IT leaders need to be held accountable for preventable compromises. Some leading institutions have largely eliminated NTLM already, demonstrating that it is possible with sufficient executive commitment. We feel that attacks on NTLM, including Zerologon, are entirely preventable. Kerberize on-premise authentication and do stateful authentication of the protocol using Q:CYBER’s Identity Assurance suite to re-establish confidence in enterprise auth.