ZeroLogon – Patching is Not Enough

Guidelines and Tools for Protecting Your Environment
from CVE-2020-1472

By Yaron Kassner, CTO and Co Founder, Silverfort

Secura recently published a whitepaper about one of the worst vulnerabilities that I’ve seen in a while. It’s called ZeroLogon, a.k.a. CVE-2020-1472. The DHS also published an emergency directive to patch affected Windows Servers. And they’re not exaggerating – the vulnerability lets an attacker create a domain admin account, just by sending unauthenticated packets to a domain controller. This means that anyone in the network can take over the entire domain.

For those interested in the technical bits and bytes – I highly recommend reading the whitepaper. The described attack is elegant and takes advantage of an inherent vulnerability in the NRPC protocol. It turns out that some people were so interested in this attack, that they developed a full working exploit and published it on GitHub. So, if you haven’t deployed the update yet, stop reading this article and do it now. Come back after you do.

As with most vulnerabilities, Microsoft published an advisory, along with a security update. While some may be tempted to install the update and forget about it, the careful reader will notice this comment: “Microsoft is addressing this vulnerability in a phased rollout.”

Yap – it’s not a good thing. A phased rollout means that during the first phase of the roll out your system is still vulnerable. A phased approach had to be taken in this case because the vulnerability is inherent in the NRPC protocol. The patch prevents the attack by enforcing an additional layer of security on top of the protocol – that is Secure RPC. Unfortunately, it is not enough to update the server side, i.e. the DC – because the clients also need to be updated for the protocol to work. Microsoft took care of Windows devices, but it didn’t provide a solution for legacy operating systems that are no longer supported or third party products. This means that enforcing Secure RPC will break these incompatible systems.

During the first phase, AD enforces secure RPC for Windows devices, which means the worst form of the attack can be prevented. But other clients may still be vulnerable.

We developed a simple tool that iterates over the domain controllers in your domain and checks whether all of them are patched. The tool is based on the original testing tool published by Secura but instead of running on one DC at a time, it will automatically find the DCs and run on all of them. We recommend that you run this tool to make sure none of the DCs in your environment have been missed – one unpatched DC is enough to compromise the entire domain.

Download The Github Testing Tool Here

Moving to Phase Two

In the second phase, AD enforces secure RPC for all computers, including non-windows devices. The second phase will be done automatically on February 2nd, but you can start it earlier, and we recommend that you do. To do that, you should first make sure that you don’t have any clients in the network that rely on non-secure RPC. Microsoft provides audit logs to discover such clients and Silverfort can help as well: You can leverage Silverfort to prepare a report that lists clients that use non-secure RPC. If you don’t have Silverfort, you can start by auditing Microsoft’s event logs.

What to do with non-secure RPC clients?

Here is my recommendation. First of all, put them into “Domain controller: Allow vulnerable Netlogon secure channel connections” group policy. This does not secure these clients , but it will allow you to move the rest of the devices into the enforcement mode now, instead of waiting for February 2021.

After you’ve moved the rest of the devices into enforcement mode, you should take care of the non-secure RPC clients. Do not leave them as is! They are vulnerable!

If these devices are 3rd party devices, you should contact the vendor and ask for a solution to make them work with Secure RPC.
If for some reason you can’t make the client work with Secure RPC, Silverfort can help protect it – see more below.

How Can Silverfort Help until all non-secure RPC clients are covered?

Silverfort monitors and controls Netlogon traffic in the network. This allows Silverfort to detect all computers using non-secure RPC. For these devices, Silverfort can increase the risk, and provide additional layers of security, like stepping up the authentication requirements to or from these devices.

So Summarizing the Recommended Steps:

1. Update your domain controllers
2. Use Silverfort’s open-source tool to see if there are any DCs left unpatched
3. Use Silverfort or Microsoft for auditing for clients using non-secure RPC
4. Put non-Secure RPC clients into the allow-list
5. Move the domain into enforcement mode as soon as possible
6. Start a process to fix non-secure RPC clients or remove them from your network
7. In the meantime, use Silverfort to protect vulnerable clients from exploitation and restrict their usage.

Yaron Kassner, CTO and Co Founder, Silverfort

Silverfort’s CTO and Co-Founder Yaron Kassner is a cybersecurity and big data technology expert. Before co-founding Silverfort, Yaron served as a big data expert consultant for Cisco. He also developed new capabilities involving big data analytics and machine learning algorithms at Microsoft. Prior to that Yaron served at the 8200 elite cyber unit of the Israel Defense Forces, where he led a reputable R&D team, raised to the rank of Captain, and received a prestigious excellence award. Yaron holds a B.Sc. in Mathematics, Summa Cum Laude, an M.Sc. and Ph.D. in Computer Science from the Technion – Israel Institute of Technology.