VMware vSphere is the most widely used virtualization platform for on-premises data centers. Similarly to other virtualization platforms, it basically relies on host servers running guest machines. These hosts and guest machines can be managed using administration interfaces such as vSphere API and VIX API. The Guardicore Labs team has discovered a vulnerability in the vSphere infrastructure that can be exploited using VMware’s Virtual Infrastructure eXtension (VIX) API. This vulnerability allows an attacker to remotely execute code on guest machines, bypassing the need for guest authentication.
This attack stands out for two main reasons. First, it’s simple and requires nothing except for a basic knowledge of the VIX API to carry out the attack. Second, it’s stealthy – no new code executes on any of the virtual machine hosts or the vSphere machine and no surprising logs are generated from this interaction on the guest machine.
In this post we’ll share some technical details about the vulnerability as well as some tools to help security teams check how exposed they are to this attack.
The VMware Host Guest Isolation
To keep virtual machines isolated from their hosts, organizations often require that their IT and infrastructure teams have no access to data kept inside the machines they administer. This isolation is crucial for compliance mandates such as PCI and HIPPA, overall separation of duties (SOD) and defense in depth. Following this logic, most companies allow their infrastructure teams to create, modify, backup and delete guest machines, but deny them permissions to guest machine operation functions such as file manipulation and program execution.
Organizations use VMware’s rich security model to isolate the infrastructure domain from the guest machine domain. VMware’s VIX API allows users with valid vSphere permissions to automate guest operations functions across VMware platform products. Using VIX to interact with a virtual machine requires the administrator to go through two distinct security domains: 1) The vSphere host; 2) The guest operating system. This two step authentication should provide the proper segmentation between IT staff and users with valid credentials to business data.
The vulnerability resides in the WMware VIX API. The VIX API has a backdoor functionality that allows for direct access to guest machines without requesting the guest OS consent.
This research was performed using the open-vm-tools (OVT) package, which is the recommended version of VMware tools and is supported out of the box on practically all Linux distributions.
As described in the WMware VIX documentation, to use the VIX API for guest operations, applications must authenticate with two distinct security domains:
1. The client must first authenticate with the vSphere host.
2. The client must then supply a valid credential for the guest operating system on any virtual machine where it wants to perform guest operations”
For guest authentication, two methods are documented by VMware: passing in a user/password combo to the guest machine which is the standard method and sharing the active console session of a logged-on user. Both methods require that VMWare tools be installed and active for any interaction.
In addition to these two methods, an additional undocumented type of authentication exists. This authentication is based on a shared secret and was created to allow IT admins to control machines using the vSphere platform before more modern configuration tools were developed.
To execute guest commands with this undocumented method, the user would have to pass in a “secret” whose hash is saved on the guest’s machine configuration file. If the hashes match, the ESXi host returns a valid credential token. From this stage, the user can pass in that token to the guest alongside a command, passed in a VIX_USER_CREDENTIAL_ROOT request.
By looking at the open vm tools source code, specifically at the block that handles the VIX_USER_CREDENTIAL_ROOT request, we can see that inside the guest, the token is not verified and that the VMware tools only checks whether authentication using a shared secret is allowed or not.
Further examination of the code reveals that if any of the following three conditions is met the attack will be successful:
1. The if code block doesn’t exist at all in the vmtools binary. until version 9.9.0, which was released in 2013, this entire if block was missing, which means that the vmtools allowed VMX root privilege command execution without any way for the guest operating system to block it.
2. Invalid requestFlags parameter. In ESX 5.5 the VMX simply copies this value from the buffer it receives from the client and forwards it to the vmtools, allowing an easy bypass of this check by the client.
3. The shared secret authentication method is enabled. Up until 9 months ago (VMware tools version 10.1), the default vmtools configuration allowed the Shared Secret authentication method, unless the administrator explicitly configured the guest machine to opt out of this method. This wasn’t trivial considering the fact that this feature wasn’t documented…
Exploiting a Machine: Step-by-Step
To exploit this vulnerability, an attacker would have to go through the following steps, each requiring different control permissions.
1. Connect to the guest using the VIX API, providing valid vSphere credentials. This requires the “Guest operating system management by VIX API” permission and is done using the VixVM_Open function.
2. Set the guest machine shared secret hash. This can be done using different APIs but requires the “Virtual MachinesConfigurationAdvanced”. Note that this is only required once per VM, after which only read permissions are required.
3. Login using the shared secret, passing in the “secret” whose hash must match the VMX file. This requires using the “shared secret” authentication type, an undocumented flag whose value is “4”.
4. Execute commands with root/SYSTEM permissions 🙂
In some cases, an attacker will be required to change the ESXi’s configuration, setting the “sharedPolicyRefCount” to a non zero value. This is required for the shared secret authentication method. Changing this requires the “HostConfigurationAdvanced settings” privilege, which isn’t a common privilege among non-administrators. However, this value is frequently changed by vSphere addons and shouldn’t be considered a core part of the attack.
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