VMware AsyncTelemetryController Arbitrary File Write Vulnerability

October 8, 2021

Overview:

  VMware vCenter Server is a data centre management server application developed by VMware Inc. VMware vCenter Server is designed primarily for vSphere, VMware’s platform for building virtualized cloud infrastructures. As part of a broader VMware stack which may include both private and public cloud infrastructure, vCenter Server has an analytics service which provides health and telemetry data to VMware’s Cloud Analytics service (VAC) in order to help diagnose and prevent issues within the environment.

  An arbitrary file write vulnerability has been reported in VMware vCenter Server. The vulnerability is due to insufficient validation of collector IDs and collector instance IDs in requests handled by the AsyncTelemetryController class.

  A remote attacker could exploit this vulnerability by sending crafted requests to the target server. Successful exploitation of this vulnerability results in the writing of a .json file with arbitrary file contents to a location of the attacker’s choosing, potentially allowing the execution of arbitrary code.

CVE Reference:

  This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-22005

Common Vulnerability Scoring System (CVSS):

  The overall CVSS score is 9.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C).

  Base score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:
    • Attack vector is network.
    • Attack complexity is low.
    • Privileges required is none.
    • User interaction is none.
    • Scope is changed.
    • Impact of this vulnerability on data confidentiality is high.
    • Impact of this vulnerability on data integrity is high.
    • Impact of this vulnerability on data availability is high.
  Temporal score is 9.0 (E:P/RL:O/RC:C), based on the following metrics:
    • The exploit code maturity level of this vulnerability is proof of concept.
    • The remediation level of this vulnerability is official fix.
    • The report confidence level of this vulnerability is confirmed

Technical Overview:

  One of the primary components of the analytics service is the Telemetry Server which exposes an API at “/analytics/telemetry/”. The Telemetry Server consists of several services which determine where the telemetry data is to be sent such as a local log file, or VMware Analytics Cloud. The sending of telemetry data is initiated by a request to one of the following URIs:

The second URI is considered the “staging” telemetry server.

  An arbitrary file write vulnerability exists in VMware vCenter Server. The vulnerability is due to the fact the class responsible for handling telemetry “send” requests does not validate or sanitize one of the HTTP request query parameters before using its value as a file path and writing the contents of the request body to the file. Requests to the aforementioned telemetry send URIs are handled by the AsyncTelemetryController class. Requests to the production URL are handled by the overloaded handleSendRequest() method and requests to the staging URL are handled by the handleStageSendRequest() method. In both cases, the request accepts three query parameters: _v, a version number, _c, a collector ID, and _i, a collector instance ID. These parameters are provided as arguments to a different overloaded version of the handleSendRequest() method which first creates a TelemetryRequest object given the version, collector ID, and collector instance ID. The method then calls the processTelemetry() method of the TelemetryLevelBasedTelemetryServiceWrapper class which first inspects the current telemetry level configured on the system then calls the processTelemetry() method of the LogTelemetryService class if telemetry is not disabled.

  LogTelemetryService.processTelemetry() first puts a path and filename into the thread context. The filename is created by passing the collector ID and collector instance ID from the request to the LogTelemetryUtil.getLogFileNamePattern() method. The method uses a format string of “_c%1$s_i%2$s” along with the collector ID and collector instance ID to create the file name. Then processTelemetry() calls the info() method of the currently configured logger to write the body of the received request to the location determined by the path and filename put into the thread context, appending the .json extension to the file as configured by the logger in the initial service definition. Due to the fact that the collector ID and collector instance ID values are not validated or sanitized, an attacker may provide a collector instance ID which contains directory traversal characters in order to write a .json file with attacker controlled contents to an arbitrary location where it may be used to facilitate execution of arbitrary code such as /etc/cron.d/.

  An unauthenticated, remote attacker can exploit this vulnerability by sending a crafted telemetry send request. Successful exploitation results in the writing of a .json file to an arbitrary location which may lead to the execution of arbitrary code as root.

Triggering the Problem:

  The server must have the vulnerable product installed and running.
  • The attacker must have network connectivity to the target server.

Trigging Conditions:

  The attacker sends a crafted HTTP request to the telemetry send endpoint of the target server. The vulnerability is triggered when the server processes the request.

Attack Delivery:

  The following application protocols can be used to deliver an attack that exploits this vulnerability:
    • HTTPS, over port 443/TCP

SonicWall’s, (IPS) Intrusion Prevention System, provides protection against this threat:

  • IPS: 15690 VMware vCenter Server AsyncTelemetryController Arbitrary File Creation 1

  • IPS: 18064 VMware vCenter Server AsyncTelemetryController Arbitrary File Creation 2

Remediation Details:

  The risks posed by this vulnerability can be mitigated or eliminated by:
    • Filtering attack traffic using the signatures provided above.
    • Applying the vendor provided patch or workaround.
  The vendor has released the following advisory regarding this vulnerability:
  Vendor Advisory