'Live' VMs at Risk While in Transit

WASHINGTON, DC -- Black Hat DC -- A researcher here today demonstrated how an attacker could hack VMware and Xen virtualization software when a virtual machine is moved from one physical machine to another.

Jon Oberheide, a researcher and PhD candidate at the University of Michigan, is releasing a proof-of-concept tool called Xensploit that lets an attacker take over the VM’s hypervisor and applications, and grab sensitive data from the live VMs.

Oberheide says organizations don’t typically realize or consider the risk of migrating live virtual machines . The last thing they want to do is take down the live system because that would defeat the purpose of the dynamic and high-availability features you get in a VM deployment.

“Enterprises [with VMs] need to be aware of these risks and make sure they’re adequately protected,” he says.

Because the data moves in clear text during a VM migration, he says, an attacker could stage a man-in-the-middle attack on a virtual machine’s hypervisor. He demonstrated how his Xensploit tool manipulates SSH daemon-based (sshd) authentication as it crosses the wire, and then gives the attacker administrative access to the VM.

“The destination [machine] doesn’t know whether it’s been a legitimate VM migration or if it was modified by an attacker,” he says.

Oberheide says the vulnerable spot is the data plane, or the path along which the VM migration takes place. An attacker can sit in the middle and manipulate that traffic to gain access to the VM system, using techniques like route hijacking, ARP/DHCP spoofing, ICMP redirection, and DNS spoofing or poisoning, he says. There is also the possibility of passive attacks, where the bad guy could merely sniff passwords.

“The serious [attacks] would be kernel exploits,” he says, where an attacker could slip rootkits or other backdoors into memory.

Oberheide says VM vendors need to shore up the security of their software. Enterprises with VM systems, meanwhile, can set up mutual authentication between the source and destination hypervisors during a migration, and either encrypt the data plane or use a separate physical network or virtual network to isolate the migrating VMs.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.