While newly-discovered malware that attacks VMware virtual machines is no cause for undue concern, users can take some basic steps to protect apps and data, says security firm Trend Micro.
Earlier this week, advanced analysis of the Morcut Mac OS X or Crisis malware that targets computers running Apple’s Mac operating system (OS) or Microsoft’s Windows OS revealed that it also targets virtual machines.
Last month, Crisis was reported to have arrived on a compromised computer through a JAR file, using social engineering techniques. Symantec detects the JAR file as Trojan.Maljava.
The JAR file drops the malware executable file for the appropriate operating system and, in both cases, opens a back door on the compromised computer.
Now researchers have found new special functions in the Windows version, including one to infect a VMware virtual machine.
According to Symantec researchers, the threat searches for a VMware virtual machine image on the compromised computer, mounts it and then copies itself onto the image by using a VMware Player tool.
The malware does not use a vulnerability in the VMware software, but takes advantage of the fact that all virtual machines (VMs) are a file or series of files on the disk of the host machine.
“This may be the first malware that attempts to spread onto a virtual machine,” said Symantec’s Takashi Katsuki. “Many threats will terminate themselves when they find a virtual machine monitoring application, such as VMware, to avoid being analysed, so this may be the next leap forward for malware authors,” he said.
Read more about malware
However, security firm Trend Micro says preliminary examination indicates that most VMware customers should be overly concerned by this news.
Most datacentre deployments of virtualisation use type 1 hypervisor deployment such as VMware ESX, which is like an operating system that controls the hardware and the hypervisor enables multiple virtual machines to execute simultaneously.
But the malware does not attack this deployment, according to Warren Wu, director, product group management datacentre business unit at Trend. “I’m not aware of malware capable of infecting type 1 hypervisors in the wild,” he wrote in a blog post.
But in type 2 hypervisor deployment, such as VMware Workstation and VMware Player, the hypervisor installs on top of a standard OS, and in turn hosts multiple virtual machines on top.
Keep up to date with security news
“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 VMware Player) 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, end-point anti-malware solutions,” wrote Wu.
But even if an infected VM is then moved and executed on a type 1 hypervisor, he said 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.
Wu points out that two things make Crisis new and unique: First, that the malware specifically seeks out the presence of virtual machines and tries to infect them, and second, it infects the VM through the underlying infrastructure by modifying the .vmdk file, rather than entering the VM through conventional means like remote network/web access or file shares.
However, despite these characteristics, Wu said Crisis does not present an immediate threat, particularly as 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 said, Wu recommends that to protect valuable apps and data, VMware users should take the following precautions:
- Secure your VM’s –Be sure to have anti-malware and other layered protection to secure both physical and virtual servers and desktops;
- Restrict VMDK access – While Crisis targets only hosted hypervisors, not the datacenter, it remains fundamental that anyone who can access the .vmdk files on a file system can do bad things to the virtual disk or the VM, and that includes for vSphere or View as well, Wu wrote.