Who is vulnerable?
For a machine to be vulnerable, two conditions must be fulfilled. One, the attacker needs valid vSphere credentials with the right permissions on the target VM. Two, the virtual machine needs to be running a vulnerable version of the VMWare tools.
The permissions required for an attack “from scratch” are “Host.Config.AdvancedConfig” on the ESXi host of the target machine and the “VirtualMachine.Interact.GuestControl” and “VirtualMachine.Config.AdvancedConfig” privileges on the virtual machine itself. However, as we’ve previously mentioned, in many cases the “Host.Config.AdvancedConfig” is redundant as the appropriate field may already have been set.
From our research, it looks like the first version of VMware tools to properly implement all the checks is 10.1, released near the end of 2016. Prior versions are either completely vulnerable or require the administrator to manually disable the shared secret authentication method.
A guest machine will be vulnerable in one of two cases:
1. Running on ESXi version 5.5
2. When running vmtools version older than 10.1.0
When installing vmtools on a Linux virtual machine, VMware suggests to use the open-vm-tools from the relevant distribution upstream repository. However, many distributions package a vulnerable version of OVT which makes them vulnerable to the attack. These include:
- Ubuntu 16.10
- Fedora 25
- RHE 7.2
- Oracle Linux 7 (latest)
Why Should I Care?
An attacker can leverage this capability to attack a network through the virtualisation infrastructure, avoiding nearly every modern defense technique. From this point, persistency is not required on any guest machine and it’s the ideal platform for data exfiltration through the control layer or for ransomware installation.
This attack allows an attacker to fully control the guest as it allows a high privilege arbitrary code execution at any time. An attacker can utilize this capability for a lateral movement across the data center, it can allow access to some isolated networks that weren’t available to the attacker otherwise. Also, this kind of access and capabilities can be easily used for a data leakage or ransomware installation.
Note that the permissions required for this attack are commonly assigned to 3rd party virtual appliances such as backup solutions. These appliances are a frequent target for compromise and can allow an attacker a quick and stealthy access.
Our first suggestion is to upgrade to a fully patched VMware tools, from 10.1 and up.
However, many supported operating systems do not provide this as part of their upstream, in which case we suggest you installing the VMware official binaries.
In case you are running ESXi 5.5, the latest VMware code won’t help, because the requestFlags field is still controllable by the attacker. Use instead our forked version of open-vm-tools which ignores this flag and always checks if this authentication type is enabled. You may also download pre-compiled binaries for some distributions.
Over the past decade most organizations have shifted the bulk of their compute infrastructure to virtualized platforms. This flaw while simple, provides a new form of lateral movement inside the virtualized network, attacking servers through their virtualisation layer and bypassing modern defenses.
Click to download the presentation