Title: vCenter Java JMX/RMI Remote Code Execution
Date Published: 01/10/2015
VMware vCenter Server provides a centralised platform for managing your VMware vSphere environments so you can automate and deliver a virtual infrastructure. VMware vCenter was found to bind an unauthenticated JMX/RMI service to the network stack. An attacker with access can abuse the configuration to achieve remote code execution, providing SYSTEM level access to the server.
|VMware vCenter Server||6.0||Any|
|VMware vCenter Server||5.5||Any|
|VMware vCenter Server||5.1||Any|
|VMware vCenter Server||5.0||Any|
Description of Issue
VMware’s vCenter application makes use of Java Virtual Machine (JVM) technology and supports the use of Java Management extensions (JMX), for application and network management and monitoring of the JVM. A JMX agent is setup to allow remote management of the JVM. The JMX agent utilises managed beans ‘MBeans’ to expose configured interfaces to manage predefined configurations. Any objects that are implemented as an MBean and registered with the agent can be managed from outside the agent’s Java virtual machine.
The JMX service was found to be configured insecurely as it does not require authentication, allowing a user to connect and interact with the service. The JMX service allows users to call the “javax.management.loading.MLet” function, which permits the loading of an MBean from a remote URL. An attacker can set up their remote Web Service to host an MLet (text file) that points to a malicious JAR file. When the JMX service registers the MLet file, the agent will initiate the URL to the remote JAR and execute the methods leading to code execution.
Wider exploit development has already been undertaken against other vendors utilising JMX/RMI deployments and therefore, publicly available exploit code already exists that can be used in combination with Metasploit to gain a remote Meterpreter shell as SYSTEM.
For a proof of concept and further discussion, please see our blog on this issue.
Reported – 27th February 2015
Accepted – 21st April 2015
First Fix – 10th September 2015
Retrospective Fix – 1st October 2015
Advisory Published – 1st October 2015