Why I'm Not So Concerned About the Rumored ESX 0day

So there has been some chatter following press coverage, like this ars technica story, of the HBGary material which appears to contain details of 0day sploits for most of the major platforms including ESX. From what I have seen, the rumored ESX 0day does not concern me terribly. Let's take a look at what is known about it and I will explain why. Important caveat: this analysis is based on what appears to be leaked information readily available on the web. Obviously I cannot authenticate the information, nor can I confirm or attribute any of these rumored 0days. I can, however, explain why the description of the exploit I have seen does not concern me and would not be as great a threat as it might appear.

The ESX 0day appears to be an remote, unauthenticated direct file access exploit of some sort. It requires (unauthenticated) access to port 443 on an ESX host. Port 443 is where the hostd service listens for connections from a vCenter server, as one can observe on an ESX host. In this netstat output, you can see an ESX host with a management IP of 192.168.1.7 has connections into hostd from a calling vCenter server (.4) and an ssh session from .100;

[root@localhost ~]# netstat -np
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 148 192.168.1.7:22 192.168.1.100:52259 ESTABLISHED 3482/0
tcp 0 0 192.168.1.7:443 192.168.1.4:49826 ESTABLISHED 3025/vmware-hostd
tcp 0 0 192.168.1.7:443 192.168.1.4:49766 ESTABLISHED 3025/vmware-hostd
tcp 0 0 192.168.1.7:443 192.168.1.4:49872 ESTABLISHED 3025/vmware-hostd
tcp 0 0 192.168.1.7:443 192.168.1.4:49777 ESTABLISHED 3025/vmware-hostd

The document I have seen talks about "stage one" and "stage two" access. In "stage one", the exploit is used to read files and download a file containing the root password hash (possibly /etc/shadow). The exploit does not apparently provide for code execution or file writes. In "stage two", the doc talks about "decrypting the encrypted password"; it sounds like the attacker simply runs the password hash(es) through a password cracker (John the Ripper is suggested). Following that, the user has "command line access and full administrator access" (I assume they mean root) to the target host. It's not clear if they have implemented a toolkit to interface with the service console or hostd or if you're supposed to do this manually. It sounds like you're supposed to use the exploit to grab /etc/shadow, crack the hashes, and then login using conventional means.

Whatever the case may be, in a defensible virtual environment, these services are simply not exposed to external attack, or even to consumer guest virtual machines. Hypervisor management services like hostd and the service console run on the primary management interfaces which live in management substrate networks to which access is well regulated. In such an environment, the attack surface for these services consist largely of substrate admins - and they already have controlled administrative access to hypervisors; they don't need an exploit. The notion that a hypervisor's management interface would be exposed to external attack, through a firewall, is not very realistic in my experience. Hypervisor service networks are often routed through additional authentication checkpoints like two factor portals or by making them accessible only to an authenticated vCenter server user. They can also be wrapped with tools like the HyTrust product which provides an additional layer of authentication and auditing.

So this is why 0days for the management services are not necessarily a crisis; in a properly designed defensible virtual environment, those who can attack the management services don't need to as they're the admins. Of course, if you have a rogue admin, you have a different (and interesting) threat model that will require logging, auditing, detection and response.