VIRTUAL MACHINE TROJANS: A NEW TYPE OF THREAT?

Virtualization technology is such an efficient way of managing IT resources that there’s no doubt that in a very short time it will become the only way of doing it. But virtualization is still a new technology, and logically the information security aspect will lag behind for some time to come. 

There are four types of security risks related to virtualization:

1) The normal, run-of-the-mill buffer overflow type any software package may have; there’s no escaping that. Take CVE-2002-0814 as an example.

2) The risk of the guest virtual machine taking control of the host physical machine. It’s easy to forget that the virtual machine is running on the same memory of the host. Therefore, the virtual machine could do a buffer overflow and take control of the underlying host machine. Such is the case of CVE-2005-4459.

3) The Blue Pill scenario, in which a virtual machine loads while the host machine is booting, and then mimics the host machine, to the point where the user does not know he/she is inside a virtual machine. In this way, the attacker has full control of the host machine, and the user would have a very hard time realizing he/she is not in control. (http://en.wikipedia.org/wiki/Blue_Pill_(malware)), (http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html)

4) Virtual machine trojans, in which a seemingly benign virtual machine you download from the Internet contains a trojan.

The objective of this article is to talk about #4, Virtual Machine Trojans (VMTs).

As we all know, trojans infect a machine masquerading as a useful program or file, and the objective of the trojan is to remotely take control of the machine for nefarious purposes: steal information, send spam, conduct click fraud, stage denial of service attacks within a botnet, etc. Since trojans have been around since ever, antivirus companies have become very adept at detecting and eliminating them, either detecting their particular signature, or using heuristics based on the behavior of the malware.

So, normal trojans are a known threat, and we know how to mitigate them. But what about virtual machine trojans? A VMT comes embedded within a virtual machine. When a user downloads a virtual machine from the Internet, and then runs it on his/her computer, the antivirus installed in the host machine simply does not have access to the virtual machine, so the virtual machine does not get scanned. If you have in place an antivirus appliance, the trojan will not get detected either while the virtual machine is being downloaded. Downloading and running a virtual machine without any precaution is almost no different than finding a server box in the street, picking it up (“oh great, a free server!”) and plugging it straight into your LAN. You just don’t know where that server’s been.

The types of attacks a VMT can execute are different than a normal trojan. The VMT does not have access to the host machine; rather, it has access to the local network. Therefore, a VMT can be programmed to do the following:

1) Sniff traffic in the local network

2) Actively scan the local network to detect machines, ports and services

3) Do a vulnerability scan to detect exploitable machines in the local network

4) Execute exploits  in the local network

5) Brute force attacks against services such as ftp and ssh

6) Launch DoS attacks within the local network, or against external hosts

7) And of course, send spam and conduct click fraud

When the virtual machine carrying the VMT is installed, the user will either assign it a static IP, or allow it to access DHCP. The virtual machine’s virtual network adapter will either come preconfigured as “bridged”, meaning that the virtual machine will have direct access to the LAN, or as “NAT”, meaning that the virtual machine will use the host machine’s IP to access the network. And of course, the VMT will be programmed to connect via internet to its control server, probably using port 80 outbound. Therefore, your firewall will very likely let the connection through. Once the VMT phones home and establishes a connection with the control server, the attacker has total control of a virtual machine inside your network, happily sending commands and receiving data through an http tunnel.

How real is the threat? I do not know. And that’s exactly the scariest type of threat. There are virtual appliance marketplaces out there, and anybody can sign up as a virtual appliance provider.  Plus there are thousands of other sites from where your users can download virtual appliances. There’s no way of knowing if they are infected with VMTs.

From the technological point of view, creating a VMT is relatively simple. Anybody with a moderate skill level in a scripting programming language can put a VMT together. I have developed a proof-of-concept VMT called ViMtruder, programmed in Python, which can be downloaded from www.infosegura.net/vimtruder.html . It consists of a client, the VMT proper, which is installed within a virtual machine, and a control server, which sits in a host on the Internet. The virtual machine, running Linux, is configured to automatically run the VMT client in the background upon boot up. The VMT tries periodically to contact the control server through the Internet using port 80 outbound. Once the control server links with the VMT, you can send it Nmap commands to scan the target LAN where the VMT is connected (Nmap is also pre-installed in the virtual machine). The control server displays and logs the Nmap scan results, revealing the open ports and services running in the target LAN.

This first version is only a proof-of-concept to show how easily it is done; ViMtruder can be further weaponized, adding an open source password sniffer (Dsniff), vulnerability scanner (Nessus), password cracker (THC Hydra), and exploit platform (Metasploit), as well as DoS scripts.

What can we do to mitigate the risk of VMTs? There are no antivirus countermeasures yet. But even if they where, think about the difficulty in implementing an antivirus against a VMT. Antivirus software sits inside a host, in such a way that if malware gets downloaded into the memory of that host, it gets easily detected. But when a virtual machine gets downloaded, its virtual memory is off-limits to the host machine. The only other way would be for an antivirus appliance to scan the virtual machine while it is being downloaded, but this would also be very difficult to do, given how hard it would be to establish recognizable trojan patterns inside the virtual machine.

These are the steps we can take to mitigate the risk of VMTs:

1) Establish a policy that prohibits the downloading and installation of virtual machines without IT’s permission. If a user needs a virtual machine, it should be downloaded and tested by the IT department first. Of course this policy will be violated, so we need to implement further defenses.

2) Try not to use DHCP, and keep a strict IP inventory. This will prevent a virtual machine from automatically grabbing an IP. Nevertheless, a determined user will configure the virtual machine with NAT, and use the host machine IP.

3) Run periodic vulnerability scans to detect the presence of virtual machines. If the scanner can authenticate into the hosts, it will be able to check the registry and report if a virtual machine server is installed. It will also be able to detect the actual virtual machines that may be running at the moment, based on the MAC address, but only within the same subnet and if you are not using a proper switch, of course.

4) Use a deep packet inspection and/or proxy firewall. Configure your firewall to check for proper protocol sequences. This will reduce the risk of a simpler trojan, but more sophisticated ones will be able to circumvent this countermeasure. ViMtruder 1.0 uses port 80, but does not create an http tunnel; it uses raw TCP. Therefore this type of firewall should be able to detect that there's something strange with the connection. (Future versions will have http tunnel and steganographic communication.)

5) Install an IPS not only on your perimeter, but also in your local network. Yes, there are companies that think that an IPS inside the local network is not necessary, since they already have a firewall. Well, trojans, worms, and insiders hack from within the local network.

6) Read the logs. Periodically check the IPs to which your internal network is connecting to in the Internet. And take into consideration that a VMT can connect to its control server through other innocent looking ports (53 for example) not only port 80.

So up to now there is no quick solution like an antivirus; you need to implement your defense-in-depth strategy, and do the legwork of checking the logs.

When a new pathogen appears, there’s a low chance of getting infected, but at the same time, if you do get infected, there is no cure. We should start taking a good look at virtual machine security, to be able to determine how real this threat is.