Virtual machine (VM) technology has many positive uses. However, when a VM is paired with a rootkit, you have a problem called a VM-based rootkit (VMBR).
VMBRs aren't just theoretical nuisances. Samuel T. King and Peter M. Chen of the University of Michigan, and Yi-Min Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch of Microsoft Research published a new white paper that discusses VMBRs in considerable detail. The white paper, "SubVirt: Implementing malware with virtual machines," is available on the Internet and is also scheduled to be presented at the IEEE Symposium on Security and Privacy in May.
VMBRs will be harder to detect than regular rootkits, but fortunately, they'll also be harder for intruders to develop and install. In a nutshell, the way a VMBR works is to load itself underneath the existing OS. The existing OS then runs as a VM on top of the VMBR. When running this way, a VMBR could go undetected unless special tools are used to look for its existence. VMBRs are possible for both Linux and Windows platforms.
Causing a VMBR to become installed is the tricky part, as is usually the case with rootkits. To cause a VMBR to run underneath an existing OS, the system's boot sequence must be modified so that the VMBR loads first. Modifying the system boot sequence requires a high level of privilege or an easily duped user. The white paper authors point out several possible inroads, including remotely exploitable system vulnerabilities, a malicious bootable CD-ROM or DVD, software from a corrupt vendor, and of course malicious software run by a naive user who's logged on with Administrator privileges.
The real danger of VMBRs is that due to their nature of running underneath an existing OS, they can remain relatively invisible to the target OS. A VMBR might or might not communicate with a target OS. If a VMBR is designed to launch Denial of Service (DoS) attacks, to relay mail, to establish pirate software drop points on other systems, or to host phishing Web sites, it doesn't need to communicate with the target OS. On the other hand, if the VMBR is designed to eavesdrop on keyboard, mouse, or network activity, then some amount of interaction must take place. But interaction could be minimized by modifying device drivers and emulators.
The team actually developed a VMBR along with several malicious services. It also modified system instructions so that user-mode VM detection wouldn't discover the VMBR. Taking the VMBR to an even further extreme, the team was able to manipulate LEDs on some computers via the system BIOS to fool users into thinking a system was shut down when in fact it wasn't!
The project is, to understate the matter, a very successful proof of concept. If you're interested in the finer details of the research, be sure to read the white paper at
http://www.eecs.umich.edu/Rio/papers/king06.pdf
