vScalation (CVE-2021-22015)- Local Privilege Escalation in VMware vCenter
Pentera’s research team ‘Pentera Labs’ discovered a vulnerability in VMware’s vCenter Server program. The affected VMware software is installed in over 500,000 organizations worldwide and is responsible for managing their most critical systems. The findings were proactively reported to VMware and later released under CVE-2021-22015.
On Sep. 21, 2021, VMware published a security patch regarding a Local Privilege Escalation (LPE) vulnerability impacting all appliances running default vCenter Server 6.5 to 7.0 deployments. The patch and additional info are available on VMware’s Advisory site.
The Pentera Labs team have created a scanner to enable validation of the patching efforts of this vulnerability to be found in our GitHub repository
VMware vCenter Server is an advanced server management software that provides IT administrators with a centralized way to manage virtualized hosts in enterprise environments. The platform is installed in hundreds of thousands of organizations worldwide and is used by organizations to manage some of their most critical assets and core systems.
Vulnerability Discovery Walkthrough
How we gained Local Privilege Escalation on VMware vCenter
vCenter has recently come under scrutiny following the discovery of several vulnerabilities affecting the platform, which can lead to shell access and vSphere takeover. One of these vulnerabilities was our starting point – “VMware vCenter Unauthenticated OVA Upload RCE” (CVE-2021-21972). Using this vulnerability, we gained shell access as a low-privileged user named “vpshere-ui”, and from there we started examining a fresh instance of a VMware vCenter Server.
While examining the processes that run on the vCenter machine with root privileges, we noticed a few from the same folder that appear to be working with Java.
Further examination of the folder revealed that there is another file for each process, which turned out to be pointing to the same file for all of the processes. They all had a link pointing to the same file under the path – “/usr/lib/vmware-vmon/java-wrapper-vmon”.
The backdoor of java-wrapper-vmon and cis group
This file is part of vCenter installation, it’s a .bash file involved in the execution of those processes. And since the processes listed above are running with root context – so is this file.
In the process of examining this file, we noticed that the “cis” group has read/write/exec privileges for it.
Our next step was to explore the origins of the “cis” group. Members of the “cis” group include not only the user “vsphere-ui” (which we exploited using CVE-2021-21972 at the beginning of our journey), but also a whole host of other users. See the screenshot below for the full list:
*This screenshot is taken from a 6.7 version and there may be changes in different versions
In other words, any one of those users can edit the file java-wrapper-vmon!
In technical terms we can describe the vulnerability in the following stages:
- Gain shell access to any of the users that are part of the “cis” group
- Add malicious code to the java-wrapper-vmon file
- Restart one of the processes served by the java-wrapper-vmon file, or the vCenter host itself
- Result: our malicious code runs as root!
- Outcome example: ransomware installation or Denial Of Service attack
A sample implementation is detailed below.
Privilege escalation vulnerabilities like this can be used by an attacker to abuse the host in countless ways, for example: by installing ransomware, mining bitcoin or causing a local denial of service, to name a few. But these are relatively minor attacks. An advanced attacker could use such privilege escalation to take over an organization completely by utilizing a combination of vulnerabilities and exploits to launch an attack vector which would be drastically more dangerous.
To remediate CVE-2021-22015, apply the updates listed in the VMware’s Advisory site. There is no known workaround.
Exploitation for Privilege Escalation (T1068)
Similarly to advanced threat actors, well-performed malware campaigns, Pentera uses the above technique for Privilege Escalation (PE).
I wanted to say thanks to everyone at VMware involved with the patch for this vulnerability. They were kind, prompt in their responses, and very easy to work with.
Experience has taught us never to trust a theoretical vulnerability until we’ve seen it exploited, and vScalation (CVE-2021-22015) is no exception.
Clearly, there are endless routes to take when validating that vScalation (CVE-2021-22015) can be used to gain Local Privilege Escalation in a VMware vCenter. The following implementation demonstrates the ability to gain root privileges by exploiting vScalation (CVE-2021-22015) to extract the /etc/shadow file from the host.
The /etc/shadow file contains the hashed passwords for all the users on the host and is only accessible with root.
Let’s add this code block to the java-wrapper-vmon file:
After restarting the vCenter host or one of the services, the script will run as root, copy the /etc/shadow file to the specified location, and give it read permissions.
Bingo! This is just a taste of the power you can obtain by getting root privileges on a vCenter machine.
Despite major investments in their security suites, organizations continue to be breached. Our Co-founder and CTO, Arik Liberzon, recently sat down with CyberNews to discuss the value of the adversarial perspective and where his inspiration from Pentera came from. Starting out, I arrived at the idea for Pentera and Automated Security Validation in a pretty...
In this post, we will examine one method of encrypting data-at-rest, specifically how to achieve Data-at-Rest Encryption for MongoDB Community Edition (CE) containers through eCryptfs. Introduction Our goal at Pentera was to implement a solution that prevents data discovery upon theft when the system is offline (e.g. if a host is stolen or someone is...
After CentOS 8 was declared end-of-life (EOL), we had to find an alternative operating system (OS) for our on-premise solution, as did many other teams and organizations. Although our deployment is container-based, we still had to prepare the groundwork for different OS areas, from security patches and network modifications to installing required packages. We had...