VM Rootkits: Dangerous, in Theory

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

It’s nice to see when people discover new vectors for attacks. It does make one go "Hrmm.." But the latest one, the virtual machine rootkit, makes me wonder how practical some of these attacks might be.

At this point, I don’t know if the rootkit in a VMM (virtual machine monitor or hypervisor) is really a practical thing, given some of the issues it will bring with it in regards to performance. The concept is rather interesting, however.

Basically, a rootkit, a piece of malware used to control a server or desktop remotely, is placed into a new virtual machine in the VMM or as a secondary virtual machine. The challenge of this is that the virtual machine is totally oblivious of this activity. It is, in effect, isolated from the virtual machine but can continue it’s malicious activities such as enabling a keylogger, starting a phishing website, and so forth as per the technical paper on SubVirt presented recently by the University of Michigan and Microsoft Research.

In my opinion, a lot of this is still theoretical, and while admittedly interesting, may not yet be practical for those pursuing less-than-ethical hacking avenues.

First, if the rootkit does create a secondary virtual machine, it’ll need to be a small enough virtual machine so as not to get noticed. On desktop or user-based virtual machine environments (or rather non-big-server virtualization) this will be noticed. Often RAM is at a premium on these environments and you’ll notice if a new virtual machine pops up using another 64MB or more of RAM. If this appeared on a larger server environment like ESX, where it’s not unusual to have servers having 16GB of RAM, it may not be as noticeable.

Each of the scenarios – that is, using the VMM or creating a secondary virtual machine – offers benefits for the attacker. A sub-VMM could be tied to a specific virtual machine but may be limited to the time that the virtual machine is actually up and running. If powered off, the advantage of the hidden VMM is lost.

In this case, the hidden VMM would have a tiny footprint to be less noticeable. It’s not to say that having a hidden, second virtual machine (one that would continue running even after the original virtual machine is powered off) couldn’t be small, say the size of a floppy disk. But at that size it would be limited to specific activities and you’d have to ensure the code is well optimized.

A decent floppy Linux virtual machine would do the trick and would work with the desktop-based virtual environments. However, a product like ESX would unlikely take well to the Linux install, largely due to the fact that only certain guest OSes have been tested on it and others often fail at install.

Secondly, even if the hit to RAM isn’t noticeable, performance and/or I/O usage will be since it will need to interact with the virtualized hardware. In most virtualization environments performance issues are usually easily detected. You will notice when CPU usage spikes or if a virtual device becomes unavailable to a virtual machine pretty quickly.

Since most malware tends to have odd effects on systems, the activity will be noticeable at some point. I wonder if, in some cases, the rootkit may call upon a new piece of virtual hardware to be installed or have an effect on specialized virtual hardware optimization tools like VMWare in order to be effect (e.g., grabbing the vmxnet driver to replace the slower vlance driver in VMWare environments).

Thirdly, there remains the challenge of the rootkit to remain stealthed at boot time. This can be overcome if it’s placed within the master boot record (MBR) of the virtual disk being used by the virtual machine. This would make it the best vector for attack. Once started, it could stay resident in virtual memory until the system is reboot or shutdown. Or, if it’s a separate VMM, continue running even with the virtual machine off. The challenge would then be to hide the VMM from the process list of the physical host.

The last challenge would be to bring it to the large server virtualization environment, where frankly, the stakes are much higher.

This research was done on Linux with VMWare and Windows with VirtualPC. On an environment like ESX or Xen it may not be as viable as it is in their desktop virtualization cousins. Additionally, the larger server environment virtualization products tend to be far more sensitive to additional code due to their stringent hardware compatibility requirements. The solution is to create an anti-virus or rootkit detection tool that checks the activities found within the VMM, particularly if this appears on true hypervisor virtualization environments such as ESX by VMWare.

Alternatively, even starting with the simple BIOS check by the virtual machine (akin to a MBR BIOS virus check that used to be done) may be an interesting start. Further, you could check for the installation of optimization tools or limit the world IDs of virtual machines to run between specific addresses. For example, if you only have 10 virtual machines running and they only require 10 IDs then limit yourself to those 10 IDs – akin to IP addressing.

Lastly, internal IDSes and firewalls can help limit the damage a rootkit like this might be able to do by enforcing policies of what is allowed in and out, as well as detecting unusual activity, particularly by behavior based IDSes.

Again, the question remains as to how viable, realistic and practical it will be to create such malware. Hrmm...

This article was first published on EnterpriseITPlanet.com.

Submit a Comment

Loading Comments...