Clarifying CVE-2020–1472 (“Zerologon”)
There’s been confusion regarding Microsoft’s patch for CVE-2020–1472 (mitigating the so-called “Zerologon” attack), what you need to do, and when. That’s not entirely surprising: this vulnerability and phased patch response is very different from anything I can recall, and Microsoft’s documentation about it is complex. I’m going to try to clear up the major issues as concisely as I can.
First: if you haven’t yet, you must apply this patch to your domain controllers (DCs) as soon as possible. Some things might break (I’ll get to that next) but those breaks can be fixed. If you don’t patch, the likelihood is rather large that someone whose interests don’t align with yours will gain complete and permanent control of your infrastructure.
The August patch treats Windows-based and non-Windows domain members differently:
- Patched DCs now require all Windows-based domain members (and non-Windows DCs) to use signing and encryption. Based on informal testing my Tanium colleagues and I have done, this won’t break any version of Windows going back at least to NT4 that have Netlogon-related security settings at the installation defaults or stronger. However, it will block computers that are explicitly configured to disable signing/encryption. You can unblock them either by strengthening their signing/encryption settings, or by creating specific exceptions for them with the new group policy described in Microsoft KB 4557222.
- Non-Windows domain members that don’t (or can’t) use signing/encryption can continue to authenticate for the time being. The patch that Microsoft plans to release in February 2021 will enforce the same restrictions on non-Windows devices that the August patch enforces for Windows-based devices. You can enforce that restriction on non-Windows devices now with a registry setting described in the KB. If you can’t change those devices to meet the new requirements, you can exempt them using the same group policy as for Windows-based machines.
How vulnerable am I without the “full-enforcement” option?
The reported exploit always depended on signing and encryption being optional. When a client cannot choose the protocol’s less-secure option, the exploit no longer works. But the patch also brings a subtle change to the Netlogon protocol that breaks the “all-zeroes” exploit technique as well as similar ones. This means that even when you have clients that you can’t require to use signing/encryption, successful exploit of the protocol’s weakness is now mathematically many orders of magnitude more difficult than it was. This lessens the immediate urgency of moving to the full-enforcement option for non-Windows devices.
You need to monitor events — here’s why:
After patching your DCs, you should determine whether any authorized computers are being blocked or will be blocked in full-enforcement mode, so that they can be updated, retired, or exempted with the new group policy setting. The August patch defines several new events that Netlogon writes to the System event log whenever vulnerable connections are blocked or allowed.
It’s important to note that the primary reason you need to monitor these events is not to see evidence of unsuccessful attacks — it is to determine whether any legitimate systems are being blocked or will be blocked, because you need to take action to keep them operational.
What’s my best way forward now?
Tanium has published content that will tell you the precise vulnerability status of your domain controllers and whether any member systems are being blocked or will be blocked so that you can keep your operations running smoothly and securely. See the references below for details.
— Aaron Margosis
Global Techno Ninja, Tanium
References:
How Tanium Can Help Find and Remediate “Zerologon” (CVE-2020–1472)
CVE-2020–1472 | Netlogon Elevation of Privilege Vulnerability
KB 4557222: How to manage the changes in Netlogon secure channel connections associated with CVE-2020–1472
