WannaTry again? SMBv3 Vulnerability Awakes!

SMBv3 vulnerability (CVE-2020-0796) explained and how to defend against zero-day attacks

While the world is struggling with real-life effects of the COVID-19 disease caused by a member of the Coronavirus family, we have just learned about a new vulnerability of the SMBv3 protocol, for which there are some concerns that it could cause an equivalent scenario in the cyber world. The vulnerability was accidentally leaked by Microsoft themselves, before a patch has been released. There is a similar case from three years ago when Shadow Brokers released a vulnerability one month after the patch was available from Microsoft. EternalBlue resulted in some of the most devastating malwares in recent years (WannaCry, NotPetya etc.).

What is it?

The SMBv3 vulnerability is disclosed under the ID CVE-2020-0796. This indicates an attack attempt to exploit a buffer overflow vulnerability in Microsoft SMB servers. The vulnerability is due to an error when the vulnerable software handles a maliciously crafted compressed data packet. A remote, unauthenticated attacker can exploit this to execute arbitrary code within the context of the application. Almost all the newer Windows versions are affected.

Why is it important?

As of the writing of this blog post, the vulnerability does not have a patch yet, which means that any attempt to exploit the vulnerability would result in a zero-day exploit (zero-day exploit means that there is no prevention for a given vulnerability). This makes this vulnerability dangerous, as we recall how SMBv1 was exploited by EternalBlue, which gave birth to the WannaCry and NotPetya ransomware attacks that caused billions of USD in total combined damage.

What can we do about it?

As long as there is no patch to fix the vulnerability, we have to rely on our awareness, some hardening of our environments, and of course workarounds. We advise organizations to follow general guidelines for more secure environments that serve to prevent damage from this kind of vulnerabilities (as well as other possible malicious activities, e.g. other ransomware).

The general guidelines are:

1. Limiting TCP port / SMB and RDP on endpoints: TCP port 445 is used to initiate a connection with the affected component. Blocking this port at the network perimeter firewall is present in almost every organization, as this protects exploitation from the outside world. However, most organizations don’t implement SMB blocking in internal networks. There is usually no real business need to have it enabled. A good practice in this case is to block SMB and RDP on endpoint workstation firewalls, as this limits worm spread by exploitation, lateral intruder movement, and also the majority of ransomware propagation.

2. Patch ASAP: One of the most obvious methods (although perhaps least used in public) is patching. Patching is a very effective way to stay safe and secured, as it usually provided fixes to bugs that enable vulnerabilities. However, patching may not be a trivial procedure in bigger IT / OT environments, as organizations mostly have to test the patches to check for any issues before deploying them on all machines – this then delays the patching itself. Data from different research studies suggests that in most corporate organizations, the patching process from release to fully-patched systems lasts several months. Worse, some servers are left unpatched because some organizations prefer not to make any alterations to them. In cases of non-patchable systems, other mitigation approaches should be used. However, at the moment there is no patch available which would fix this particular vulnerability!

3. Network segmentation and limiting SMB to servers: Most corporate networks suffer legacy issues, and we have grown from times where flat networks (having workstations and servers in the same network) were a feasible idea. In modern times, the number of servers and endpoints has grown. Network segmentation is one of the most important steps you should take, because it lays the foundation for limiting insider or outsider threat actors’ success. Most organizations’ networks are simple, segmented into the DMZ and internal networks. Some organizations have already implemented segmentation, but don’t employ firewalling either between segments or on the servers. The proper way to handle this is to limit access to server resources only to groups of users that should have access on the network layer. If the compromised machine is in a specific segment not able to connect to critical data storages or servers, an adversary will have a hard time with lateration and exfiltration of critical data. Having no segmentation at all is usually a “disaster waiting to happen” in terms of either advanced attacks or simple ransomware damage, since sometimes admins turn off server firewalls for troubleshooting purposes and forget to turn them on again.

Mitigation for the current vulnerability:

4. Disabling SMBv3 compression

You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 server with the PowerShell command below.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

• No reboot is needed after making the change.
• This workaround does not prevent exploitation of SMB clients.

You can disable the workaround with the PowerShell command below.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force

Some General Stats

In our Security Operations Center (SOC), we tested certain environments with vulnerability assessment scans in order to detect enabled SMBv3 on devices – just to get some insights on an average potential attack surface for our clients.

In corporate environments, we see a lot of SMBv2 usage and unfortunately still a little bit of SMBv1. A very small amount of SMBv3 usage is in the production environment (under 10 percent). That means that the risk for organizations is not so significant, but it still needs to be identified and managed in a proper way. There is still a chance that an adversary will laterate in the internal network by exploiting this vulnerability. As of the time of this writing, there is no publicly exposed exploits or any POC exploits available. In the near future, it is likely that we will see exploitations of this vulnerability used by different malicious codes.

Some Good News

At the time of writing this blog post there are no known abuses of the vulnerability in the wild. It may be far too early to make any bold statements, but hey – we have to feed positive spirits too!

As the above statistics show, most organizations also don’t have as high of a percentage of vulnerable systems in their networks as was the case with the EternalBlue vulnerability.

As long as you follow the above-mentioned guidelines on hardening your environment, you will be a lot safer until an official patch comes to fix the vulnerability.