Malware analysis

VMware vCenter vulnerability: Inside a critical remote code execution flaw

May 5, 2021 by Pedro Tavares

VMware addressed a remote code execution (RCE) vulnerability in VMware ESXi and VSphere Client virtual infrastructure management platform that could be exploited by criminals to execute arbitrary commands and take control of the vulnerable systems. Let’s dive into this critical vulnerability, highlighting the most important details of this flaw.

The RCE flaw allows an unauthenticated user to send a specially crafted request, which opens the door for the execution of arbitrary commands on the server-side. The flaw was tracked as CVE-2021-21972 and has a CVSS score of 9.8, affecting several versions of the software.

“A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server,” the company said in its advisory. [CLICK IMAGES TO ENLARGE]


Figure 1: VMware flaw-affected versions.

Details of the VMware RCE vulnerability

This vulnerability (CVE-2021-21972) could be used by criminals to breach the external perimeter of an enterprise data center by taking advantage of backdoors already installed on a system to find other vulnerable points of the network to take over the affected systems.

A second vulnerability — a server-side request forgery (SSRF) — was also discovered by PT Swarm, the company that discovered these vulnerabilities. The CVE-2021-21973 with a CVSS score of 5.3 allows unauthorized users to send HTTP-POST requests to execute further attacks, including the ability to scan the target’s internal network and retrieve information about the open ports of various services.

Researchers found an unauthorized request didn’t require any kind of authentication on the following component: /ui/vropspluginui/rest/services/*.

Figure 2: Vulnerable plugin on VMware VCenter.

The web application relies on plugins installed on the server-side, and the PT Swarm researchers found that a specific plugin is not well-configured, allowing unauthorized users to access any URL it handled.

In this way, the uploadOvaFile function responsible for the URL was analyzed in detail and explored to get an RCE condition as described below.

Figure 3: Part of the vulnerable code used to upload an arbitrary file into the server-side.

As highlighted, during the file upload step, a copy of each current entry is created on disk using the file naming convention: /tmp/unicorn_ova_dir + entry_name. The problem here is that the names of the .tar entries are not filtered, and can be modified to take advantage of “path traversal + RFI” due to bad development on the file parser function.

According to the researchers, “This meant we could create an archive entry containing the string “../,” which would allow us to upload an arbitrary file to an arbitrary directory on the server.”

By using a .tar evil file and uploading it, researchers were able to create a file on the server-side as presented in figure four.

python evilarc.py -d 2 -p ‘testFolder\’ -o win -f winexpl.tar testUpload.txt

Figure 4: Text file uploaded inside an arbitrary directory (created by researchers).

From web shell to RCE

From this point, it’s possible to upload arbitrary files into the server-side. To get an RCE condition, a web shell can be used by sending the next .tar file with the target path.

python evilarc.py -d 5 -p ‘ProgramData\VMware\vCenterServer\data\perfcharts\tc-instance\webapps\statsreport’ -o win -f winexpl.tar testRCE.jsp

As noted, the testRCE.jsp web shell is created on the target path, and an RCE condition is obtained with system privileges.

Figure 5: RCE condition obtained via web shell.

Here, we see the web shell was successfully uploaded into the server-side and executed with system privileges — higher privileges on Windows systems.

RCE on Linux

On Linux instances, the challenge can be a little bit different, but very trivial as well. Instead of uploading a web shell, researchers can take advantage of the SSH service to add a trusted machine into the authorized_keys file and then get a valid SSH connection.

python evilarc.py -d 5 -p ‘home/vsphere-ui/.ssh’ -o unix -f linexpl.tar authorized_keys

Figure 6: Malicious authorized_keys file created with the researchers’ public keys.

Next, the vulnerable system can be reached via SSH.

Figure 7: Valid SSH connection within the vsphere user context.

Avoiding VMware risk and vulnerabilities

VMware VCenter is a technology largely used around the world inside internal networks allowing the management of several and critical assets. With this vulnerability in place, criminals can successfully move through the internal networks and gain access to the data stored in the vulnerable systems, including virtual machines, system users and more.

Through this point, an internal reconnaissance can be done using the vulnerable machine as a pivot in lateral movement attacks.

It’s highly recommended that users update their systems to eliminate the risk associated with the flaws, and also remove VCenter Server interfaces from the perimeter of the organizations and allocate them to a separated VLAN with limited access on the corporate network.

 

Sources:

VMware VCenter vulnerability, PT Swarm

Advisory VMSA-2021-0002, VMware (hyperlink: https://www.vmware.com/security/advisories/VMSA-2021-0002.html)

Posted: May 5, 2021
Articles Author
Pedro Tavares
View Profile

Pedro Tavares is a professional in the field of information security working as an Ethical Hacker, Malware Analyst and a Security Evangelist. He is also Editor-in-Chief of the security computer blog seguranca-informatica.pt.

In recent years, he has invested in the field of information security, exploring and analyzing a wide range of topics, such as malware, reverse engineering, pentesting (Kali Linux), hacking/red teaming, mobile, cryptography, IoT, and security in computer networks. He is also a Freelance Writer.