Vulnerability Spotlight 1: ZeroLogon
Welcome to the first post in the NCSC’s Vulnerability Spotlight series. These articles will examine a range of security vulnerabilities disclosed throughout the last year, covering a number of different domains. This series is intended to raise awareness of the types of vulnerability that are found across a range of technologies, discuss what organisations can learn from them, and hopefully spark some further conversations. Each post will give a high-level overview of a vulnerability, add our thoughts on its implications, and provide some further reading.
With introductions out of the way, let’s get straight into the first vulnerability.
CVE-2020-1472, aka ZeroLogon
ZeroLogon is a vulnerability in the Netlogon Remote Protocol utilised by Windows Server. The vulnerability takes advantage of a flaw in the cryptography implementation of the protocol. This is a severe vulnerability as it only requires an unauthenticated attacker to have network access to a domain controller, yet a successful exploitation attempt can give the attacker domain administrator privileges. ZeroLogon has received a CVSS score of 10.0 from Microsoft (for reference, the CVSS scale only goes up to 10.0).
This vulnerability was first reported on August 11, 2020 by way of a security update and patch from Microsoft. It didn’t receive much immediate notice due to the lack of technical details published. However, after a whitepaper was released which detailed an exploit proof of concept, the vulnerability garnered much more attention.
The Netlogon Remote Protocol is a remote procedure call (RPC) interface that is utilised by domain controllers for a range of authentication tasks on a network, including user and machine authentication. Netlogon utilises a custom cryptographic protocol to authenticate communications between clients (domain users and machines) and servers (domain controllers). It is the implementation of this custom cryptographic protocol that contains the flaw which enables the ZeroLogon vulnerability.
When Netlogon is used by a client to authenticate with a domain controller, a shared session key needs to be generated so that the domain controller can verify the identity of the client. After a connection is set up, Netlogon allows for the subsequent session to be either encrypted (‘sealed and signed’) or unencrypted. Either way, the session key is used for authentication. The session key is then used to compute a client credential, which is ultimately what is used by the domain controller to authenticate the client. Netlogon uses the AES-CFB8 cryptographic scheme for this credential computation. It is the flawed implementation of this scheme that leads to the underlying vulnerability.
AES-CFB8 is a block cipher, meaning it encrypts fixed sized blocks of plaintext into encrypted ciphertext. It requires a random initialisation vector (IV) to be appended to the start of the plaintext. The IV value must be unique and randomly generated in order to implement AES-CFB8 securely. However, the function that Netlogon utilises to compute the client credential always sets the IV to a value of 16 zero bytes. Due to the way AES-CFB8 is implemented, this results in a 1-in-256 chance that an all-zero plaintext will be encrypted to an all-zero ciphertext.
This property can therefore be utilised by an attacker to spoof any client (user or machine) credential. Since the client controls the generation of the challenge for the session key, this can be set to all-zero by an attacker. The attacker doesn’t know when the randomly generated session key on the server will lead to an all-zero client credential, but since machine accounts are not locked after invalid login attempts, the attacker can keep repeating authentication attempts until the all-zero credential matches with a session key. Using this method, an attacker can spoof any machine on a domain, including the domain controller itself.
After an attacker gains the ability to send Netlogon calls as any machine, they can then use the NetServerPasswordSet2 call to set a machine password to a zero-length password. Doing this for the domain controller account allows the attacker to log on to the domain controller using this zero-length password, thus giving them access to sensitive information stored in Active Directory. The attacker can then pull the password hashes for any account, including domain administrators. These hashes can then be used in a standard pass-the-hash attack. This gives the attacker domain administrator privileges.
ZeroLogon shows that critical security vulnerabilities remain a serious issue even amongst mature, widely used and well-known technologies and products. Given that multiple proof of concept (PoC) exploits were released shortly after ZeroLogon’s disclosure, it is no surprise that reports of exploitation in the wild emerged quickly after. For organisations not keeping up to date with patching their domain controllers, this is a very serious issue.
Tying this into the New Zealand Government’s Protective Security Requirements (PSR), mandatory requirement INFOSEC 4 states that organisations should be “keeping up to date with evolving threats and vulnerabilities”. While other security controls may provide defence in depth to protect against this type of attack, being aware of emerging vulnerabilities and patching as soon as updates are available from vendors is still absolutely critical in order to ensure the security of your organisation.
References and further reading