On August 21, widespread media reports began to circulate that a new virus or malware was attacking VMware virtual machines. “Crisis” (aka Morcut) is a new family of malware that began circulating in late July, and was reported by many anti-malware vendors, including Trend Micro, as principally infecting Mac OSX machines. Security researchers have recently uncovered that some new variants of Crisis also can infect VMware virtual machines and Windows Mobile devices.
Trend Micro is still researching all the potential implications–so any comments here are preliminary, but we do not believe that most VMware customers should be overly concerned by this news. Here’s a practical guide to what you need to know to sort through the FUD, and whether you should do anything in the short-term or long-term.
Just as a refresher, there are primarily two types of Hypervisor deployments used for virtualization today:
- Type 1 Hypervisor deployment – Prime examples are VMware ESX, Citrix Xensource etc. It would help to think of these products as replacing the Host OS (Windows/Linux) and executing right on the actual machine hardware. This software is like an Operating system and directly controls the hardware. In turn, the hypervisor allows multiple virtual machines to execute simultaneously. Almost all Data Center deployments use this kind of virtualization. This is NOT the deployment this malware attacks. I’m not aware of malware capable of infecting Type 1 Hypervisors in the wild.
- Type 2 Hypervisor deployment – Example VMware Workstation, VMware Player etc. In this case the hypervisor installs on TOP of a standard operating system (Windows/Linux) and in turn hosts multiple virtual machines on top. It is this second scenario that the malware infects. First, the Host operating system is compromised. This could be a well-known Windows/Mac OS attack (with the only added wrinkle being the OS is detected and the appropriate executable is installed). It then looks for VMDK files and probably instantiates the VM (using VmPlayer) and then uses the same infection as that used for the Host OS. This type of an infection can be stopped with up-to-date, endpoint antimalware solutions.
Even if an infected VM is then moved and executed on a Type 1 hypervisor (for arguments sake), it is restricted to just that VM because the endpoint security agent will protect against inter-VM network traffic as well as I/O traffic.
So what’s the big deal?
VM’s, just like physical machines, are certainly no stranger to malware infections through unpatched flaws in the guest OS/apps, or through end-user social engineering. Two things make “Crisis” new and fairly unique:
- First, that the malware specifically seeks out the presence of virtual machines and tries to infect them
- Second, that it infects the VM through the underlying infrastructure, i.e. by modifying the .vmdk file, rather than entering the VM through conventional means like remote network/web access or file shares.
All the interesting aspects aside, we do not feel that there is an immediate threat from this malware. The actual rate of incidence in the wild is very low (less than 100), so it does not appear to be widespread or capable of spreading quickly. That being said, there are some precautionary measures you should take if you’re concerned:
- Secure your VM’s – it is your valuable apps and data that are the ultimate target of any attack, “Crisis” only made that more explicit. Be sure to have anti-malware and other layered protection to secure both physical and virtual servers and desktops like Trend Micro™ Deep Security ™ or Trend Micro OfficeScan™.
- Restrict VMDK access – while “Crisis” only targeted hosted hypervisors, not the datacenter, it remains fundamental that anyone who can access the .vmdk files on a file system can do a lot of bad things to your virtual disk or the VM, and that includes for vSphere or View as well
Written by: Warren Wu | Director, Product Group Management Datacenter Business Unit