Zero Networks Labs

Implications and Mitigations for SMBv3 Remote Code Execution (SMBGhost)

Published March 12, 2020 by Sagie Dulce

Update (April 21, 2020)

A working exploit POC code, along with writeups and deep dives, can be found here, provided by the excellent ZecOps team.

What Could This “Potentially Wormable” Vulnerability Mean for You

A recent remote code execution (RCE) vulnerability, dubbed by some #SmbGhost or #CoronaBlue, ’ has been found, CVE-2020-0796, in the way the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests. If exploited, it could allow attackers to target SMBv3 servers, as well as clients, and execute code to ‘worm’ their way into the device and establish a foothold.

Ultimately, if successful, it could allow an attacker to move laterally and potentially take control over your domain. The exploit does not require authentication and currently has no mitigation; there is only a partial workaround, which entails disabling SMBv3 compression.

A Secret That’s Not so Secret

This bug was not ready to be famous just yet. It appears that Microsoft first leaked information about this issue by mistake. Apparently, Microsoft published the bug (ZDNet presented a couple of hypotheses about where) and then immediately pulled it back, but it wasn’t fast enough, as several security firms issued advisories, such as Talos and Fortinet. This left Microsoft no choice but to release additional information, in their own security advisory.

Microsoft's initial advisory made it clear why this vulnerability was shared by mistake, namely because there was no mitigation, but they just issued a fix, KB4551762, for Windows 10, versions 1903 and 1909, and Windows Server 2019, versions 1903 and 1909.

For those cases where a patch cannot be applied, Microsoft does offer a partial workaround for servers - they suggest disabling SMBv3 compression; for clients, there is nothing to do, but wait for a patch. Another, more sweeping, recommendation is to block inbound and outbound traffic to port 445 - yep, just like the good old days.

One of the most effective ways to mitigate the risk of exploiting this vulnerability, or any other SMB vulnerability for that matter, is to prevent SMB traffic from making any lateral connections and entering or leaving the network. This will shut down attackers, without disrupting legitimate users, but it has been hard to accomplish quickly and effectively, at scale, until recently.

Details of the SMB RCE Vulnerability

What’s Affected

This vulnerability affects:

  • Windows 10 versions 1903 and 1909.
  • Windows server versions 1903 and 1909.

Establishing an Initial FootHold

An attacker who figures out how to exploit this vulnerability will be able to target SMBv3 servers, as well as clients, without any authentication whatsoever, and execute code. In order to get an initial foothold the attacker has two options: find a vulnerable SMB service online, or set up their own ‘SMB server ‘trap’ and get clients to attempt to log in, using social engineering tactics, such as sendinding or embedding malicious links in emails or web sites.

Propagating the Attack - Lateral Movement

Once inside, the attacker is free to move laterally in the network by targeting any host with an open SMB port. This will not only spread the attack, enabling the attacker to jump between hosts, but also allow them to collect additional credentials and access.

Completely Taking Over the Domain

If a domain controller (DC) is running on one of the affected installations, pay attention - an attacker could go straight for the domain controller over SMB and completely own your entire network.

The SMB port has to remain accessible for your entire network, because it is a requirement for sharing group policy objects, as well as to facilitate file replication between DCs.

Mitigating the Risks of SMBGhost

Luckily, as of the writing of this blog, there have been no known public exploits of the remote code execution. There is however an existing denial of service proof along with a root cause analysis.

What can you do? When the Advisory says, “You can disable compression to block unauthenticated attackers from exploiting the vulnerability,” it gives us a big clue as to where we should start looking and what we can do.

Like Microsoft recommends, the first immediate steps should be to:

  • See which servers are vulnerable to this exploit (you can use this script to do that).
  • Deploy the patch, or otherwise disable SMBv3 compression on them (using this for example).
  • Note, prioritize your DCs, if they are running a vulnerable version.

You can also implement measures to shut down lateral movement to prevent an attack from propagating and gaining control over your domain. (If you would like to see how the Zero Networks Access Orchestrator can help you quickly and easily shut down internal attack vectors, such as these, please reach out to schedule a demo.)

We will update this blog as new information or developments become available.