This story has been updated here on February 8.
Security researchers are reporting an explosion in the compromise of VMware ESXi hypervisors with over 500 machines hit by ransomware this weekend, with the automated attacks likely exploiting CVE-2021-21974.
As The Stack published, some 20 ESXi machines were reportedly being ransomed every hour, with Shodan data showing that the majority were hosted by OVHcloud but the blast radius was expanding rapidly.
Customers in France appeared to initially be worst-affected and the country’s CERT-FR among the first to publish an advisory. The semi-automated attacks may be targeting unpatched and internet-exposed instances using CVE-2021–21974, a VMware ESXi OpenSLP HeapOverflow leading to RCE, CERT-FR suggested.
See also: Securing cloud workloads - from runtime to remediation
Whilst VMware's initial advisory in 2021 for the vulnerablity said that it affects ESXi versions 7.0, 6.7 and 6.5, the attacks also appear to be hitting earlier build versions; some debate continues also as to whether CVE-2021-21974 is the sole mechanism by which exploitation is happening with CVE-2022-31696 also under the spotlight, although that latter ESXi sandbox escape bug requires local access to exploit; they may be being chained.)
Admins should ensure unpatched ESXi servers are firewalled, with no ports exposed. VMware's earlier mitigation for the vulnerability urged users to 1: Login to the ESXi hosts using an SSH session (such as putty); 2: Stop the SLP service on the ESXi host with this command: /etc/init.d/slpd stop (nb The SLP service can only be stopped when the service is not in use; users can check thh operational state of SLP Daemon: esxcli system slp stats get 3: Run this command to disable the service: esxcli network firewall ruleset set -r CIMSLP -e 0
OVHcloud said February 3: "A wave of attacks is currently targetting ESXi servers. No OVHcloud managed service are impacted by this attack however, since a lot of customers are using this operating system on their own servers, we provide this post as a reference in support to help them in their remediation.
"For Bare Metal customer using ESXi we strongly recommend in emergency :
- to deactivate the OpenSLP service on the server or to restrict access to only trusted IP addresses (https://kb.vmware.com/s/article/76372)
- to upgrade you ESXi on the latest security patch
"In a second time, ensure:
- your data are backed up (on immutable storage?)
- only necessary services are active and filtered with ACL to only trusted IP adresse
- monitor your system for any abnormal behaviour.
"Our clients using VMware Private Cloud are not impacted. By design, the SSL gateway prevent this typology of attack by blocking the external access to this port (OpenSLP 427)" the cloud provider added.
What is CVE-2021-21974?
VMware initially described CVE-2021-21974 (CVSS 8.8) in its February 2021 VMSA-2021-0002 advisory as letting a “malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.”
Lucas Leong, the security researcher who initially reported the vulnerability via the ZDI, had published a short blog in March 2021 with an overview on how to exploit the vulnerability, noting that “Service Location Protocol (SLP) is a network service that listens on TCP and UDP port 427 on default installations of VMware ESXi. The implementation VMware uses is based on OpenSLP 1.0.1. VMware maintains its own version and has added some hardening to it. The service parses network input without authentication and runs as root, so a vulnerability in the ESXi SLP service may lead to pre-auth remote code execution as root. This vector could also be used as a virtual machine escape, since by default a guest can access the SLP service on the host…”
(It was not immediately clear why it has taken this long to monetise CVE-2021-21974 given that proof-of-concept exploits have circulated since at least May 2021, but it may be that someone has only just automated a script.)
One security researcher,Habib Karataş, also suggested that the attack had flaws, saying that in at least one instance “these super smart friends only encrypted the config files on the system and prevented the system from seeing the disks. Here is the solution” he suggested.
“1- Delete the encrypted config files. 2- create an empty virtual machine. 3- Open the config file on the new machine and put it in the directory of your encrypted machines. -Replace the information in the config file with the encrypted machine names. 5- Go to the Vmware screen and "register VM" and continue on your way.”
(This does not appear to be the case for all affected ESXi users…)
CERT-FR said tartly on February 3 that “ these attack campaigns appear to be exploiting the vulnerability CVE-2021-21974, for which a patch has been available since 23 February 2021"...
Users should also revisit VMware’s vSphere Security Guide to evaluate and take action on ESXi hosts as well as VMware's existing Ransomware Resource Center which provides guidance to organisations to "remain resilient to ransomware attacks through practical approaches, system hardening, and process improvements."
Security researchers at Orange Cyberdefense told clients: "Most advanced ransomware players do indeed try to go after ESXi servers. Nevada ransomware, a newcomer in the field, was recently detailed by cybersecurity vendor Resecurity, and first thought to be behind this latest outbreak. Yet, this remains to be confirmed and is most probably a misunderstanding. Nevada started recruiting affiliates in December in one prominent Russian-speaking cybercriminals' forum. But the ransom note used doesn't align with the one we've seen sent in this campaign. The note looks like the ones used by many ransomware, including Cheerscrypt. What is confirmed is that a relatively small ransom (i.e. 2 BTC) is demanded, which means the campaign could not be real Big Game Hunting by some of the most famous and ransomware threat actors, but more probably massive yet opportunistic campaign by a less advanced attack group. We advise you to check your servers' version, and if outdated (i.e running a version lower than 6.7 and vulnerable to CVE-2021-21974 and/or CVE-2022-31696), to patch it ASAP."
