Zerologon is the name given to a vulnerability identified in CVE-2020-1472. It comes from a flaw in the logon process: The initialisation vector (IV) is set to all zeros all the time, while an IV should always be a random number.
This dangerous vulnerability has a 10 out of 10 (CVSS v3.1) for severity from the Common Vulnerability Scoring System (CVSS). There are known active proof-of-concept (POC) exploits, and it is very likely that we will see real-world attacks soon.
The Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive ordering civilian federal agencies to immediately patch or disable all affected Windows servers and warned non-governmental organisations to do the same. Microsoft released the first of two patches in August 2020, and they need to be applied to all domain controllers.
This vulnerability exploits a cryptographic flaw in Microsoft’s Active Directory Netlogon Remote Protocol (MS-NRPC). It allows users to log on to servers that are using NT LAN Manager (NTLM).
The biggest problem with this vulnerability is that MS-NRPC is also used to transmit certain account changes, such as computer service account passwords. Thinking back to its origin, it is possible to see the rationale for adding this feature. However, lack of validation in the source of the request to change these passwords has become a significant security issue.
It gets worse from here. The encryption that was added to MS-NRPC was not chosen wisely. In 1883, Dutch cryptographer Aguste Kerckhoff published 2 essays, entitled La Cryptographie Militaire (Military Cryptography), outlining the 6 key principles for designing cryptographic systems.
The best-known of them, Kerckhoff’s Principle, states that we must keep our cryptographic key secret. And we shouldn't rely on the secrecy of the algorithm to protect our data, but use well-known, well-tested, well-proven algorithms.
The algorithm originally used to encrypt the logon process in Windows NT was 2DES, which we now know has issues. Today MS-NRPC uses the Advanced Encryption Standard (AES), considered the benchmark for encryption.
In addition to choosing a proven, strong algorithm, additional settings must be selected to ensure adequate strength. MS-NRPC uses an obscure setting known as Advanced Encryption Standard – Cipher Feed Back 8bit (AES-CFB8). AES-CFB8 is obscure because it is not well known and not well tested.
The use of AES-CFB8 within MS-NRPC has an issue with the IV which should be a random number, but MS-NRPC has it fixed at a value of 16 bytes of zeros. That is anything but random. It is predictable. Cryptography is often broken where there is predictability.
How we know about this vulnerability
This vulnerability was announced in September 2020 by Tom Tervoort, a Dutch researcher working for Secura. The vulnerability was actually patched in August, but it wasn’t until the researcher published his report in September that we started to see POCs and other activity.
Tervoort’s paper details his discovery and the process that led to it. During his research, he noticed a significant lack of information about MS-NRPC. Intrigued, Tervoort pursued more information.
While Tervoort was initially looking for a person-in-the-middle attack, he discovered another vulnerability detailed in CVE-2020-1424. Continuing his research, he identified what is now known as Zerologon.
The critical part of his discovery is that Microsoft implemented a unique variation of cryptography that is different than all other RPC protocols. In the days of Windows NT, accounts assigned to a computer were not identified as a first-class principal. That meant that Microsoft could not use the standardised Kerberos or NTLM to authenticate computer or machine accounts.
As a result, the developers produced an alternative. It is incredibly difficult to create code and protocols for encryption that are not crackable. In fact, it can take an incredibly long time before the flaws are uncovered, as is the case here.
How the attack works
This vulnerability allows a hacker to take control of a domain controller (DC), including the root DC. This is done by changing or removing the password for a service account on the controller. The hacker can then simply cause a denial of service or take over and own the entire network.
For attackers to exploit this vulnerability, they must be able to set up a transmission control protocol (TCP) session with a DC. If they are inside the network physically, they could be at a user's desk or at an open port in a location such as a conference room.
These exploits qualify as insider attacks – the most expensive attacks for a business today. They can be established from outside the network so long as they can gain a foothold somewhere to establish the TCP session to the controller.
Using AES-CFB8 with a fixed IV of 16 bytes of zeros, Tervoort discovered there is a likelihood that one of every 256 keys used will create cipher text that has a value of all zeros. This is an exceedingly small number of keys for the attacker to try to create cipher text of all zeros. It would take just a matter of 2-3 seconds, at most, for the hacker's computer to do this.
So why does this matter?
If the machine communicating to a DC belongs to a user who is just going about the day as usual, there is no real issue. This poorly constructed encrypted text occurs, but the network authentication process will work. The problem only shows up when a hacker tries to exploit the system.
In the attack proven by Tervoort, the hacker would first have to spoof the credential or password of a client on the network. Due to the poor implementation of the IV within MS-NRPC, it only takes about 256 attempts to get it right.
Normally a user’s account would be locked after three attempts at guessing a password, but the same does not hold true for a computer or a machine account. When a computer is logging on there is no limit set on wrong password attempts, which allows for a continuous burst of attempts in a short time for hackers to get in. They have to find one of the keys that does produce an all-zero cipher text.
What can the hackers do once they have spoofed the identity of a computer on the network? With that first step of spoofing an identity accomplished, the attacker would not know the actual encryption key for the session. The attackers have only been able to spoof their identity by finally hitting one of the 256 keys that produces an all-zero cipher text. The next step is to disable “signing and sealing.”
RPC signing and sealing is the mechanism used for transport encryption within MS-NRPC. This seems like a logical process as we should encrypt more of our data in transit. Within MS-NRPC, however, this is an optional feature that is turned off by simply not setting a flag in the header of a message.
Once signing and sealing is turned off, messages are sent in the clear. Hackers would be able to take any action they wanted, including removing a password or setting it to another value. There will be a patch from Microsoft in February 2021 to mandate signing and sealing.
The third step is to change the password for the account that has been spoofed. The most effective device to be spoofed would be an AD server, preferably even the root AD server. To change the password, attackers use the message NetServerPasswordSet2 in MS-NRPC.
It is possible to change a password by simply sending the frame with the preferred new password. The easiest approach is to remove the password or set it to a blank value – the hacker can now log in through a normal process.
If the attack targets a random computer on the network, that computer would not be able to log in. So the first consequence of this attack is simply a denial-of-service attack against that computer.
There are now multiple public POC exploits available. If the AD servers are not patched, great damage can be caused to businesses, as the attack could be used to inject ransomware into a network.
There are tools to check if your servers are susceptible. Tervoort and Secura released a tool on GitHub to verify that your domain controllers are patched or discover if they are vulnerable.
The patch for CVE-2020-1472
In August 2020, Microsoft released a patch for CVE-2020-1472 (Zerologon). All AD servers (2008 R2 and above) should be patched as soon as possible. But the average time from patch release to deployment is still too long.
Researchers state that in the average organisation, it takes between 60 to 150 days (about 5 months) after a patch is released to finally be installed. This is known as the Mean Time to Patch (MTTP).
Unfortunately, the newly-issued patch is not the universal fix for the problem. Microsoft is planning to release a second phase of the patch, which will include the enforcement capabilities, in early February 2021.
At that time, all devices will be required to use the secure channel mode. If they do not, they will be denied access. If there are older non-compliant devices, they will have to be manually added to a group policy that explicitly allows access to non-compliant devices.
Traditional security measures should always be applied to watch for compromised accounts and networks, malicious traffic, and other indicators of compromise. Intrusion prevention systems (IPS) and antimalware software for the network and host devices (all endpoints) are critical to monitor for ransomware, viruses, and other threats.
Logs need to be collected, centralised and analysed by a SIEM. Once the logs are analysed, there should be people and processes in place to respond to indications of compromise (IoC). Then an incident response team with strong procedures and knowledge should take over to decide the extent of the compromise and work towards a resolution.
Even with the availability of a vendor patch, many customers still need time to deploy the patches and implement additional security measures to protect their environment. The concept of virtual patching through tools like IPS gives administrators and security professionals an additional tool in their arsenal.
It helps buy critical time to secure their networks. Vendor patching is still the recommended mitigation. Virtual patching solutions help protect unpatched machines. In many circumstances, they also give valuable insight into post-patch exploitation attempts on a network through features such as log inspection.
Trend Micro customers can find out more about best practices for addressing the vulnerability and how we can help by visiting this knowledge base article: https://success.trendmicro.com/solution/000270328