Ransomware scum launch wave of attacks on critical, but old, VMWare ESXi vuln
- Reference: 1675665014
- News link: https://www.theregister.co.uk/2023/02/06/esxi_ransomware_campaign/
- Source link:
We get a little language lesson with this one: France's CERT describes this as an attempt to "déployer un rançongiciel," while Italy's Agenzia per la Cybersicurezza Nazionale – which has also [2]warned of the campaign – warns that a "rilascio di ransomware" is under way.
Neither nation's infosec authorities offer any information about the source of the attack, but both note that it goes after CVE-2021-21974 – a 9.1/10 rated bug [3]disclosed and patched almost two years ago in February 2021.
[4]
CVE-2021-21974 affects ESXi 7.0, 6.7 and 6.5. The latter two versions exited support in October 2022.
[5]
[6]
We're sure those of you running unsupported and unpatched code have good reasons to do so. You now have very good reason to change your behavior tout de suite , because ransomware-slingers don't launch campaigns unless they see some rich targets. And targets don't come much richer than ESXi – the bare metal hypervisor can afford access to many guest machines that run apps and store data.
[7]Logfile management is no fun. Now it's a nightmare thanks to critical-rated VMware flaws
[8]VMware warns of three critical holes in remote-control tool
[9]VMware refreshes desktop hypervisors, adds Apple Silicon support
[10]Citrix patches critical ADC flaw the NSA says is already under attack from China
Thankfully, the ransomware deployed in this attack is a bit crap. France-based cloud OVH has [11]observed the campaign and believes the encryption sometimes fails and that data is not exfiltrated. Decryption tools are also [12]already available .
The org has also observed the following indicators of compromise:
The compromission vector is confirmed to use a OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs actually show the user dc-ui as involved in the compromission process.
Encryption is using a public key deployed by the malware in /tmp/public.pem
The encryption process is specifically targeting virtual machines files ( .vmdk , .vmx , .vmxf , .vmsd , .vmsn , .vswp , .vmss , .nvram , *.vmem )
The malware tries to shutdown virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected, resulting in files remaining locked.
The malware creates argsfile to store arguments passed to the encrypt binary (number of MB to skip, number of MB in encryption block, file size).
The above should help users to determine if they've been targeted by this campaign, and potentially infected by ransomware.
VMware, meanwhile, [13]warned on February 2 of an Arbitrary file deletion vulnerability in version 17.x of its Workstation desktop hypervisor. CVE-2023-20854 is rated 7.8/10 as "a malicious actor with local user privileges on the victim's machine may exploit this vulnerability to delete arbitrary files from the file system of the machine on which Workstation is installed."
Upgrading to version 17.0.1 knocks it on the head. ®
Get our [14]Tech Resources
[1] https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/
[2] https://www.csirt.gov.it/contenuti/rilevato-lo-sfruttamento-massivo-della-cve-202121974-in-vmware-esxi-al01-230204-csirt-ita
[3] https://www.theregister.com/2021/02/23/vmware_vsphere_critical_bugs/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y@Dd0YyvsElKGuObagctrwAAAEY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y@Dd0YyvsElKGuObagctrwAAAEY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y@Dd0YyvsElKGuObagctrwAAAEY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2023/01/25/critical_vmware_flaws/
[8] https://www.theregister.com/2022/11/09/vmware_workspace_one_assist_critical_flaws/
[9] https://www.theregister.com/2022/11/21/vmware_workstation_fusion_updates/
[10] https://www.theregister.com/2022/12/14/chinas_apt5_attacks_citrix_adc_flaw/
[11] https://blog.ovhcloud.com/ransomware-targeting-vmware-esxi/
[12] https://enes.dev/
[13] https://www.vmware.com/security/advisories/VMSA-2023-0003.html
[14] https://whitepapers.theregister.com/
Re: The virus entered via email on a Windows system
You can say it : Outlook.
We know.
Attack Surface
Are people really going to leave something as ancient as v6.5 with ports exposed on the Internet?! I'd just assume all old kit is vulnerable, VPN access only.
Re: Attack Surface
Yes, we all naturally assume that competent people are in charge.
Until we find out that the beancounters had their say.
Well, I'm sure the beancounters are going to have a chance to revise their opinion (not that I'm saying they'll change it, it's too early for April Fool's day).
Re: Attack Surface
From the VMware advisory:
"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."
So not anything to do with ports exposed to the "Internet".
For us, the COVID-19 rules caused a lot of disruption to data centre access and we've not been able to upgrade/patch a whole raft of systems. Remember ESXi is used by a lot of smaller companies who don't have enough servers to warrant a lot of automation and remote patching capabilities. One data centre I haven't been able to get people on site to since March 2020. Sure I could use 'remote hands' with the data centre staff, but for this security advisory and many others we just simply blocked the problem port on the firewall and disabled the service.
Re: Attack Surface
You know you can patch ESXi via vSphere Update Manager remotely, right?
Why there may be unpatched versions around: money
I didn't know this until I was called in to try and help a customer who actually had this infection.
The virus entered via email on a Windows system (as far as I could trace), which still seems to be the most common entry vector of any infection I've come across. It eventually found the VMWare ESXi Linux box which was left unpatched and proceeded to encrypt its contents, so eventually nuking all the VMs it was running and presto - death.
On querying why this box was running an old version of ESXi I was told it was a cost cutting measure by a since then sacked director. It turns out there are apparently two types of licenses for VMWare, with the more expensive one allowing you to update without taking the system down. As they weren't prepared to spring for the more expensive one, the much needed update conflicted with the need to keep making money, and naturally the bonus-generating option won. Repeatedly. Until they got breached so hard there was literally nothing running anymore.
I'm sure the aformentioned idiot will only mention his cost savings in his new job, not the consequences..