The VMWare vRealize Operations Manager Appliance has an authenticated REST API called "Suite API" that is accessible through TCP port 443. Some of the API calls accept HTTP POSTs with payloads of “relay-request” in XML or JSON format. There are two vulnerabilities, that when used in conjunction, lead to an authenticated low-privilege user to achieve remote code execution.
#1 Suite API CollectorHttpRelayController RelayRequest Object DiskFileItem Deserialization (CVE-2016-7462)
This issue is due to arbitrary Object deserialization through the Suite API and the Apache Commons FileUpload library being on the classpath. Specifically, CollectorHttpRelayController deserializes base64'd objects stored in the "relay-request" XML. An attacker can exploit this by embedding a manipulated DiskFileItem in the XML. There are a few URLS that can be used to reach this controller (e.g. https://[target]/suite-api/internal/relay/heartbeat).
Attacks via this vector are limited to writing (with custom content) and moving files, but not overwriting. The library is designed so that uploaded files are created with partially static names ("upload_%u_%u.tmp" where one %u is a UUID and the other is a one-up counter) that cannot be controlled by the attacker. Even when moving files, the same type of random name implementation is used, which is a limiting factor. Alone, this vulnerability can be used to upload and move files with the privileges of the web server, allowing for an effective denial of service. For VMWare vRealize Operations, this attack allows for moving web server files, the database, files in /usr/lib/vmware-vcops, files in /storage/, and more. Just through basic experimentation, we found that moving files out of /storage/ caused the device to stop allowing remote terminal logins oddly enough.
#2 Commons Collections InvokerTransformer Class Java Unserialization Remote Code Execution (CVE-2015-6934)
This issue has been disclosed before for Apache Commons Collections, as well as many dozens of vendors who implement the library in such a way as to allow remote code execution. However, in regards to VMware, vRealize Operations is mentioned in the VMSA-2015-0009 advisory for the Commons Collections issue. However, there is a footnote under the affected product table that says "Exploitation of the issue on vRealize Operations, vCenter Operations, and vCenter Application Discovery Manager is limited to local privilege escalation." The vector we discovered allows for remote access, via a single combined POST request. Since exploitation is limited by a few factors, such as not seeing your command output, uploading or downloading a custom binary is not reliable, and tools such as wget or curl aren't likely to be found on a Windows target, exploitation in conjunction with the FileUpload issue puts you on a gravy train with biscuit wheels.
Due to CVE abstraction for the Apache Commons Collections issue being tracked on a per-vendor basis, this vector will fall under CVE-2015-6934.
Exploitation Note:
When POSTing to https://[target]/suite-api/internal/relay/heartbeat as an example, you will be prompted for a username/password via basic authentication. Additionally, you will need to include these two lines in the HTTP header:
- “
X-vRealizeOps-API-use-unsupported: yes\r\n”
- “
Content-Type: application/xml\r\n”
Apache -vs- Vendors, Attributing Blame:
We brought the FileUpload issue to Apache's attention a while back and they do not see it as a vulnerability. In their response to us, they stated:
"Having reviewed your report we have concluded that it does not represent a valid vulnerability in Apache Commons File Upload. If an application deserializes data from an untrusted source without filtering and/or validation that is an application vulnerability not a vulnerability in the library a potential attacker might leverage."
Tenable argued that if an application intends to deserialize DiskFileItems then they are still vulnerable to the altered object and they could have files written anywhere on their server, which seems to cross the privilege boundaries intended by the library based on the code.
Based on our research, there is no warning about distrusting this object included in their library, or mentioning the potential for problems. It seems like there could be a few lines of code to prevent the unintended aspect of this (files written to arbitrary locations), while still maintaining the functionality of the library. In doing that, it would add a layer of protection for companies that implement the library (which many do, and we are finding vulnerable).
After another Apache person mentioned that "java.io.File is serializable, too .. And, I assume that an intruder who manages to have a DiskFileItem created and getInputStream() invoked on it, can just as well create a File (or a String), and invoke new File(Input|Output)Stream?" We reminded them that the act of deserializing a DiskFileItem can cause arbitrary files to be written to disk. The attacker does not need to invoke a new outputstream because DiskFileItem's readObject() function has already done that for him. This is not expected behavior as best we can tell. This is also not at all like deserializing a Java.io.File. That said, we respect Apache's stance on this and are contacting vendors that implement the Commons FileUpload library in a way that makes their software vulnerable.