CVE-2020–1472 — ZeroLogon gone to the Stray dogs #fireeye_2020.1
CVE-2020–1472 is rated as a10/10 critical CVSSv3 vulnerability.
Little do we know when the news hit that the cybersecurity giant FireEye got hit big time and some of their red team tools got into the wrong hands, and they were humble enough to admit the breach and disclose the level of the damage so that others could take preventive measures or even better test the attack somewhere, not recommended just saying. ;) (expect a proof of concept in a home lab for this soon…) EDIT: AS PROMISED THE LINK TO THE VIDEO (https://youtu.be/-jXp0Bmu4BU)
The August 2020 Patch Tuesday warned that from Server 2008 through Server 2019, the bug is present in most supported versions of Windows Server. Installing Microsoft August 2020 security patches on all Active Directory (AD) domain controllers (DC) immediately is strongly recommended.
An intruder with a TCP link to an unpatched DC could obtain the privileges of the domain admin, change the password, and lock you out of your environment completely before you can close chrome by opening task manager. ;)
To make things more exiting or worse there’s even a GitHub script for this
The first of two patches for CVE-2020–1472 vulnerability may have been released by Microsoft back in August, but it was not until mid-September when the team at Secura, a Dutch security company, released its whitepaper explaining the vulnerability in greater detail that the global cybersecurity community realized the possible danger and devastating effect of CVE-2020–1472 vulnerability, tossed the name Zerologon.
The global cybersecurity community has been collaborating for a proof-of-concept (POC) code for armed Zerologon attacks since the white paper published in mid-September.
A full Microsoft patch is scheduled for February 2021, should the attackers find a workaround for the patch in August 2020. The exploitation window for Zerologon remains open from now until then.
Zerologon lives up to its 10/10 CVSSv3 severity ranking, a feat only previously accomplished by 6.2 percent of reported CVEs, across all POCs, reports, and analyses released. That’s as bad as they can get in this weird year of 2020.
An attacker with a TCP link to an unpatched AD domain controller in your environment can bypass the privilege mechanism and gain domain admin privileges in a few seconds by exploiting the CVE-2020–1472 vulnerability.
Why stop there though and miss out all the fun? -_-
The intruder may alter the domain password from there, thus fully controlling the domain controller of Windows AD and completely locking you out of your system.
This is already a seriously dangerous denial-of-service attack, but the attacker might go even further and install malware on all computers under the domain, such as ransomware.
In potential attacks, state-sponsored threat groups are highly likely to use the CVE-2020–1472 exploit as well as try to work around the August patch. It is difficult to estimate the extent of the possible harm and must not be taken lightly. but oh well, what can we possibly do lol. (maybe switch to Linux?).
As mentioned earlier, for the last few weeks, POC code for weaponized CVE-2020–1472 attacks have been appearing online, and cyber attacks like a weaponized CVE-2020–1472 have recently been observed in the wild in several unrelated automated attacks, only days apart.
A custom Mimikatz module, a tool widely used by attackers to execute Credential Dumping and PowerShell attack scripts, was used in one attack.
A simplified Netlogon Remote Protocol (MS-NRPC) flowchart is shown below, a Windows domain controller remote procedure call (RPC) interface most commonly used to authenticate users and computers on domain-based networks.
On the left is the masking of the attacker as the client (the internal endpoint joined to the domain controller). The target is on the right— the domain controller.
It is important to note that the attackers first need to set up a TCP connection with an AD domain controller in your environment in order for CVE-2020–1472 to be exploited by attackers.
The client typically sends the domain controller a Client Request, a random 8-byte nonce, first and then the DC generates its Server Challenge, which should be another random 8-byte nonce.
The Session Key for subsequent use between the two parties is created with a shared secret, a hash of the computer account password of the client, via a key derivation feature (KDF) after the Challenge exchange between the two parties is completed.
The client then uses this session key for a silent credential to be computed. If a matching credential value is recalculated by the server, it is assumed that the client knows the session key and thus is a permissible client.
In the lack of vulnerabilities, the server will not pass the authentication in the fourth stage since the attacker would not know the Session Key and could not successfully compute the Client Credential.
Therefore the authentication call could be successfully bypassed if there was a way to determine the Client Credential without having to know the Session Key.
Since the client controls the initial Client Challenge, there is little to stop an attacker from setting the Client Challenge to 0000…0.0.
This unlocks the weakness of CVE-2020–1472.
When the Client Challenge consists of 8 zeros for every 1 out of 256 session keys, the right ClientCredential will also consist of 8 zeros.
The server will create a new Server Challenge each time the intruder tries to authenticate with 8 zeros, thereby creating a unique Session Key for each attempt.
All that attacker has to do is continue to create unique Session Keys before one that passes authentication is hit. 256 attempts should take approximately three seconds for a professional attacker worth his salt.
Any attacker with a TCP link to the AD domain controller, including backup domain controllers or even the targeted domain controller itself may log in as any system, using this attack method.
Due to a weakness in AES-CFB8 encryption, CVE-2020–1472 occurs when an Initialisation Vector (IV) is specified as 16 zero bytes by the ComputerNetlogonCredential function.
There is a high probability (1/256) that an all-zero ciphertext will be generated when AES-CFB8 encryption is applied to an all-zero plaintext (such as a 16-byte IV).
So what’s this AES-CFB8?
When you need to encrypt less than the required 128 bits needed for AES-CFB encryption, AES-CFB8 is one solution without having to find an alternate method of padding the leftover bytes.
The IV will prefix the plaintext with AES-CFB8.
The first byte of the operation result gets compared with the next round after AES performs an operation on the first 16 bytes of IV + plaintext.
Then the operator’s first byte is XORed and modified.
The simplified version’s execution process consists of the following:
IV = Randomized 16 bytes stringkey = Predefined KeyProc:
input = IV + plaintext[:16]
output = AES_op(input, key)
input_2 = output[0]
output_2 = XOR(plaintext, input_2)[0]
plaintext = output_2 + plaintext[1:]
repeat Proccypher = plaintext
The following figure takes as an example the content submitted by Jarvis to modernnetsec[2].
First, AES op would calculate the first byte of the IV to calculate 64.
To get the first byte, byte 10, of the ciphertext, byte 64 is then XORed with the first byte of the plaintext, byte 74.
At the same time, the newly created ciphertext 10 will become the last byte of the IV and the first byte of the IV will gradually rotate.
Then, AES-op also calculates the second byte of the IV to calculate 73, and the second byte of the plain text 65 and 73 are determined to calculate the second ciphertext 16.
Similarly, the latest IV would also contain this cypher text.
Causes and Utilisation of AES-CFB8 Vulnerability
In Netlogon AES-CFB8 the problem arises when the IV is set to 000…00 in each calculation and not randomised.
The first byte of the ciphertext generated by the first round of calculations is also 0 when the attacker sets the plaintext to 000…00, and the first byte of the input in the next round will also be 0.
Eventually, this chain effect leads to AES-performance op’s being 000…00, making the encryption useless.
The attacker will successfully use this weakness at this stage to check their identity with the DC server with an average probability of 1/256.
IV = 000…00 (16 bytes)
plaintext = 000…00 (16 bytes)
key <= Predefined KeyProc:
input = IV + plaintext[:16]
output = AES_op(input, key)
input_2 = output[ 0] == 0
output_2 = XOR(plaintext, input_2)[0] == 0
plaintext = output_2 + plaintext[1:] == 000..00
repeat Proccypher = plaintext == 000…00
The following figure also uses the example of Jarvis[2] to explain the two essential points that follow:
1. Unsafe IV configuration: Enabling IV to be set to 000…0000
2. Controllable plaintext: Allowing the client to set the Client Challenge to 000…00 also allows for efficient selected plaintext attacks.
We can see in the above figure that if the plaintext is set to 0, a chain reaction could be induced, resulting in the ciphertext being 0.
You need to try several times to accomplish this situation (at most 256 times) before you encounter a collection of keys that are still 0 after encrypting 0.
After only 256 times, the attack should be effective once-an extremely high likelihood of encryption is met.
Mimikatz lsadump:: Zerologon Integration Hacking Tool
CVE-2020–1472 Mimikatz integrations started appearing online within 24 hours of the publication of the Secura Zerologon Whitepaper.
It was just a matter of time for cyber attacks incorporating the exploit of CVE-2020–1472. Less than a month later, there were real-world attacks targeting the Zerologon vulnerability.
In a series of tweets on September 24, Microsoft said they were “actively tracking the activity of threat actors using exploits for the CVE-2020–1472 Netlogon EoP vulnerability, dubbed Zerologon.”
It was observed recently that strains of weaponized CVE-2020–1472 vulnerability were used, just days apart from each other in several unrelated automated attacks.
A custom Mimikatz module, a tool widely used by attackers to execute Credential Dumping and PowerShell attack scripts, was used in one attack.
The following figure illustrates the attack code that appeared just days after the Secura Whitepaper release for the customised Mimikatz code on GitHub.
There were approximately 2,000 attempts made. This far exceeds the 256 times required for success to be guaranteed; the attackers wanted in.
NetrServerReqChallenge is used in the loop to submit an Authenticator.Credential Client Challenge set to 0, and then NetrServerAuthenticate2 is used for authentication, with Authenticator.Credential set to 0, too.
NetrServerPasswordSet2 is called instantly to change the DC password if the authentication is successful.
Mimikatz was modified on September 18 to allow pack encryption (RPC C AUTHN LEVEL PKT PRIVACY), which invalidated the pattern matching method of detection for network layer packets.
Even if your own AD is not on the external network, using an armed CVE-2020–1472 exploit, attackers will still be able to gain access to another internal network computer and attack the internal AD.
Following patching, are there risks?
Although the initial value of the IV was not altered by the Microsoft patch in August 2020, the patch checks whether the first five bytes of the Client Challenge are sufficiently randomized, leaving the likelihood of causing the vulnerability to be approximately one in 40 billion, which should be sufficiently safe before the more full patch is released in February 2021.
Brief Exploit Overview and How to Fix It
The NetLogon remote protocol from Microsoft is commonly used to check user accounts, device accounts, etc.
NetLogon’s encryption authentication algorithm, however, contained an extreme loophole this time, which could allow an attacker with a TCP domain controller link to spoof an arbitrary identity to log in to the domain controller, gain admin access, and change the password of the Windows AD domain host.
There is a serious reach and possible effect of this exploit and it should not be taken lightly.
An attacker’s potential intrusion attack mechanism using this vulnerability can be basically simplified as follows:
- Gain a TCP connection to the targeted environment’s domain controller.
- Leverage the vulnerability of CVE-2020–1472 to spoof legit clients and connect with the targeted domain controller.
- Use the Netlogon Protocol’s built-in password setting feature to change the domain controller’s computer account and password.
- Use the changed machine account password to use attacks such as DCSYNC to obtain the account password of the entire domain, and then manage the entire domain.
The latest solution and repair methods are to update the Windows Active Directory domain controller as soon as possible in response to the CVE-2020–1472 vulnerability and related attack methods, and allow the mandatory mode according to official Microsoft recommendations.
Microsoft has published KB4565349, KB4565351, KB4566782, KB4571694, KB4571702, KB4571703, KB4571719, KB4571723, KB4571729, KB4571736 for various versions of Windows servers.
The new cyber world is eccentric and hazardous.
Although early patching and patching also help maintain defences, regular cyber health checks in the enterprise are often important to obtain full insight into the current cyber situation in an area.
Enterprises should also deploy an intelligent protection solution for detection and response that can respond effectively to known and unknown threats, particularly as modern threats, such as CVE-2020–1472, can appear suddenly. And every day more zero day exploits are appearing and are used in the wild.
If you read this far and is interested in sharing your knowledge or have any questions feel free to contact us and find the patron link so we could both sit by and enjoy some coffee while observing the next article on what happened at fireEye and more to come.
References
[2] “Zerologon — hacking Windows servers with a bunch of zeros”, by Paul Ducklin.
[3] “Micropatch for Zerologon, the perfect Windows vulnerability” (CVE-2020–1472)”.
