VMware vCenter Server is the centralized server management software for VMware, and is used to manage virtual machines, multiple ESXi hosts, and all dependent components from a single centralized location. It is widely used by enterprises for their production and testing of application servers both in their local networks as well as in their hybrid cloud infrastructure.
A remote code execution vulnerability has been recently reported in the vSphere client plugin of VMware vCenter server. It is because of improper validation of directory paths in the uploaded tar archive (OVA). This vulnerability has been assigned CVE-2021-21972. More details about CVE-2021-21972 and various affected versions can be found at NVD.
In this blog, let’s take a close look at how this vulnerability works.
Vulnerability Details:
In our lab, we hosted VMware vCenter 6.5 build 16374022 to recreate the attack scenario.
Below are how the network details looks like while configuring the server:
Below marked is the vulnerable vCenter server version:
Below marked is the vulnerable vCenter server build number:
vSphere client is accessible through web browser:
vSphere client plugin uses “/ui/vropspluginui/rest/services/uploadova” endpoint to receive OVA files. Once an OVA file is uploaded, the request handler method uploadOvaFile implemented in com/vmware/vropspluginui/mvc/ServicesController.java extracts non-directory file objects from OVA to “/tmp/unicorn_ova_dir” folder. It parses the file name from the file object header and concatenates the extracted path to the base path without checking the file name for directory traversal characters such as “..”. As a result, attackers can upload malicious files to their intended locations.
Although the “/ui/vropspluginui/rest/services/uploadova” endpoint is supposed to be accessed only by an authenticated user, we could see that it is accessible without authentication as well. Therefore, it is combination of authentication bypass and directory traversal.
We demonstrate this with below steps:
Create a dummy test file-based archive:
Upload the file to vulnerable server without authentication:
Verify the uploaded test file:
Remote Code Execution:
To exploit the server, we try to do the following:
- Validate whether the server is vulnerable or not.
- If yes, upload a customized payload with public key or webshell in it.
- Get reverse shell by connecting from attacker machine.
- Get webshell by entering the webshell address on attacker machine.
Validate the vulnerability by sending below query to the server:
$ curl –i -s -k $’https://192.168.2.143/ui/vropspluginui/rest/services/getstatus’
Even with an unauthorized request to /ui/vropspluginui/rest/services/*, the server responds with 200 OK.
We can see that GET is not allowed, POST is allowed:
$ curl –i -s -k $’https://192.168.2.143/ui/vropspluginui/rest/services/uploadova’
This is validated by sending the same request with POST method.
$ curl –i -s -k -X $’POST’ $’https://192.168.2.143/ui/vropspluginui/rest/services/uploadova’
In the above response, it is looking for the ‘uploadFile’ parameter in the POST request. It means, vCenter is ready to accept the file as input.
To get the shell of the vCenter, we should get access to SSH service. It is using the ‘vsphere-ui’ user access permissions while uploading the file. Since it accepts the file upload, we can generate public key on the attacker machine and upload it to vCenter Server’s ‘vsphere-ui’ user SSH directory and try to connect to the server via SSH using the private key, then we can achieve the shell of the vCenter server.
This is how it goes:
Let’s verify the SSH service is running or not,
It is running SSH service. So, we can proceed further and generate public key on attacker machine.
We will generate the key pair:
Upload the public key and exploited the vulnerability.
$ python3 vmwarevcenterserver70-upload.py -u https://192.168.2.143 -f /home/natraj/.ssh/id_rsa.pub
Uploading the public key to vCenter server:
Response from vCenter server:
Verifying the public key:
This is how we reach the shell on the vCenter server. With this user connected, an attacker can copy any files to the victim machine and execute them.
We can even exploit this vulnerability and use webshell as payload.
$ python3 vmwarevcenterserver70-upload.py -u https://192.168.2.143 -f webrce.jsp -t webshell
Verified the user,
Remediation and Conclusion:
Juniper Networks’ NGFW SRX customers with an IDP license are protected against compromise of this vulnerability using the signature:
HTTP:CTS:VMWARE-VCENTER-RCE
This signature was released immediately on 26th Feb 2021 with Out-of-Band Export #3359 and is part of the recommended template.
At the same time, those affected by CVE-2021-21972 should upgrade the vCenter server to the latest version, as advised by the vendor.