Last updated on Tuesday 14th of March 2023 07:23:38 PM

Massive ransomware attack affecting ©VMWare ©ESXi servers

How to protect your infrastructure, act before it's too late

The attack

A massive attack affecting ©VMWare ©ESXi servers servers has taken place and is still going on. Many clients have contacted us asking for advice and a way to protect their data.

The attack vector was confirmed to exploit an OpenSLP vulnerability that could have to do with CVE-2021-21974, this has still not been confirmed. Some older versions of ©VMWare ©ESXi have a heap overflow vulnerability affecting their OpenSLP services and this has most probably been the way the attackers have been able to sneak their malicious code in.

This issue affects servers running ©VMWare ©ESXi 6.X and early versions of the 7.0 branch. ©ESXi-7.0U3f-20036589 is known to be safe.

Selling ESXi root access
Any server behind a firewall with basic filtering is safe from this threat. The most vulnerable servers are cheap dedicated servers lacking any perimetral security. ©ESXi includes a toy FW with very little configuration possibilities. This makes that in the vast majority of the cases people use this servers as they are, with all services activated and open to the world, ready to receive attacks from anybody with the will to perform them.

How do you know if you have been affected by the ransomware?.

It is rather obvious, as the attackers disable the SSH and Web GUI and place a text asking for the ransom.

Affected services

As said the affected service in this ocassion is OpenSLP.

Service Location Protocol (SLP) is an Internet Engineering Task Force (IETF) standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.

As you are probably wondering: do I need this?

Well, most probably not. In fact most probably you don't need many other services listening in the ©ESXi management interface.

So the thing is that you can be affected by some malware that encrypts all your data just because you are attacked through a service that you aren't even using. Sounds a bit dumb, doesn't it?. This is a veiled critic to ©VMWare developers, who hinder the use of OpenSSH, an industry standard with no known bugs since more than 10 years ago, but leave dozens of open services which most people won't be using, even when they know they contain some well known vulnerabilities.

Take action

As you have already imagined, the wisest thing to do as a first measure is to open only those services that you'll be using. This is a list of the services in ©ESXi and their default state (as of ©ESXi 6.7.0):

vsandevicemonitord off    
vsantraced off    
vsanObserver off    
ESXShell off    
DCUI on   Console user interface. The nCurses UI you can see when you boot ©ESXi.
ntpd off    
SSH on   The industry standard secure shell protocol.
vsanmgmtd off    
cmmdsd off    
clomd off    
ddecomd off    
vitd off    
epd off    
vsanvpd off    
esxui on   The Web User Interface
upitd off    
osfsd off    
iofilterd-vmwarevmcrypt on   I/O filter
swapobjd on   vSan related service
usbarbitrator on   Pass through service to open USB devices in VMs
iofilterd-spm on   VM Encryption, Storage IO Control
sensord on   The VMware ESXi computer system sensor discovers VMware ESXi servers
storageRM on   Storage Resource Manager
hostd on   Host agent responsible for managing most of the operations on an ESXi host
sdrsInjector on   Storage related, not well documented
nfcd on   Moves data blocks between ESXi servers, used for replication
iofiltervpd off    
vvold on   Storage related, not used in standalone ESXi servers
rhttpproxy on   Only used to access the Embedded Hosts Client (the HTML5 interface)
hostdCgiServer on   A standalone CGI service that handles all HTTP requests for URL /cgi-bin
lbtd on   Load Base Teaming service. Unneded if you don't use teaming.
rabbitmqproxy on   A proxy running in ESXi that communicate VMs to AMQP brokers in vCenter
vmfstraced on   VMFS related service, not well documented
nfsgssd off    
pcscd off    
slpd on   Service Location Protocol (SLP) discovers network services
dcbd on   Data Center Bridging, coalesces LAN and SAN traffic
nscd on   Undocumented
cdp on   Cisco Discovery Protocol
lacp on   Link Aggregation Control Protocol
smartd on   The well known SMART service to monitor disks health
memscrubd on   Memory scrubing service
vobd on   Daemon that VMware and third-party apps use for monitoring and troubleshooting
vpxa on   Acts as an intermediary service between the vpxd in vCenter hostd on ESXi
lwsmd off    
vit_loader.sh on   vSAN iSCSI Target svc
We leverage this script to stop vit service during ESX shutting down
sfcbd-watchdog on   Disabling this service will disable some sensors reported in the hardware health status
wsman on   SOAP management interface
snmpd on   The well known SNMP protocol
xorg on   Xorg is required to start graphics devices in shared mode vSGA. vSGA not on all GPUs
vmsyslogd on   Syslog service
vmtoolsd on   Virtual Machine Tools service

Not all the above services open IP ports, some do though. Some others are local services, but they still use memory. Per instance, if you will not be using iSCSI you may turn all related services off.

There are a number of services in the above list that we can just turn off to reduce memory consumption and to reduce the attack surface.

For the case being, namely the OpenSLPD service the below code snippet will suffice

/etc/init.d/slpd stop;chkconfig slpd off

What it does is to turn the SLPD daemon off and disable the service so that it is not started again in case you reboot the server.