While looking on twitter this morning I discovered a tweet that pointed to the following article, which is relatively devoid of details but none-the-less extreme interesting to those who follow virtualization security: Fired techie created virtual chaos at pharma company. This article points out an external attack that lead to management access of a virtual environment. Now we do not know if the attack was using antiquated credentials or some other means. But what we do know is that VMs were deleted by an external source that used to be a former employee. Hoax or not, this is a very serious issue brought to light.
Rob Randall and his team at VMware as well as myself an others have apparently been fighting a rear-guard action to prevent such abuse within any virtual environment. Now it has happened. There is an absolutely need to firewall from any network but a management network any access to the virtual environment command and control layers. The reason, is that there are at least 6 ways to manage any virtual environment and any such access should be rigorously controlled.
The failure outlined within the article is not only a access issue, but an process and policy issue. Given how fast attacks are developed we can no longer put things off till the next day but need to do the end-of-job actions immediately: remove any authorizations, disable VPN connections, audit the virtual environment for any hidden gems such as a rogue management interface, verify management network firewalls to only allow very specific access such as RDP or VNC.
We may never know the details of the attack but we can surmise that the attacked company did not have proper security or policy in place, nor does it look like they had proper separation of duties. No one administrator should have all the keys to the kingdom and if they do, those are the ones you need to audit regularly. It is important to implement the controls mentioned within the End-to-End Virtualization Security whitepaper as well as perform an internal audit that is not restricted in scope to just the virtual environment, but encompasses the entire environment. Yes, this will take a bit of time but given the attack discussed it is important. Such an audit should look for rogue VMs (such as those running within VMware Workstation, Player, or Fusion, Oracle Virtual Box, Microsoft Virtual Server, Parallels, etc.). Such VMs are running within Type 2 hypervisors and are relatively invisible to any virtual environment management tool, yet should not be to security tools.
All security professionals, should understand the footprint of all the tools that can be used to manage the virtual environment, where those tools exist, and whether they are authorized. Finding these hidden devices and components are a not a new aspect of virtual environment security but are now brought to the light and should be found within any environment. Even though a tool could be written it needs to understand VMs within VMs as well as VMs within type 1 and type 2 hypervisors in order to find all the possible instances of such tools. Nor should we ignore Linux or MacOS in favor of windows when creating such tools.
In short, audit your entire environment, do not limit your scope to just the virtual environment and immediate management nodes. Nor should we rely on the audit, but enforce the process to remove access and authorizations when a person leaves, if not before hand.