How secure is your virtual environment? In this video, you’ll learn about avoiding VM sprawl and how to protect against VM escapes.
<< Previous Video: Virtualization Overview Next: Cloud Deployment Models >>
With virtualization, it’s very easy to build a computer out of the resources available in your virtualization environment. So you simply click a button, and you’ve built a web server. You click another button, and you have a database server. It’s also very easy to create virtualized networks and virtualized security systems, such as firewalls.
Well, you can see where this might be going. You go to a meeting first thing in the morning, and they need four systems for development. Then you go to your meeting before lunch, and they need three more systems to be able to perform testing. And then after lunch, there’s a new project, and they need 10 new systems to get things started.
This can obviously get out of hand very quickly, as you begin provisioning all of these new systems to run in your virtual environment. And pretty soon, you have systems running that you don’t exactly remember why they were created to begin with. This virtual machine sprawl means that you’ll have virtual machines running that you aren’t sure which application is associated with. This means that those resources will be very difficult to de-provision, so that you can then use those resources for another project.
To prevent this from happening, you need some type of formal process, so that you can create detailed documentation when a virtual machine is created, the applications running on that virtual machine. And then you’ll be able to perform audits and determine if any of the existing VMs need to be de-provisioned.
When these virtual machines are running, they are their own self-contained system. They have their own virtual CPU and virtual memory and other virtual resources, and those resources don’t interact with a hypervisor or with any other virtual machines. Or do they?
With a virtual machine escape vulnerability, the bad guys are able to break out of the virtual machine and interact directly with the host operating system, the hypervisor, or the hardware itself. The security implications for this are significant. If you’re able to escape out of the existing virtual machine and control the underlying host, you have access, potentially, to all of the other virtual machines running on that host. This is why you want to be sure to always keep up to date with all of the security patches for your virtual environment, to avoid any cases of someone who may be able to break out and escape out of their VM.
These virtual machine escapes have become very popular lately. One that got a lot of press happened in March of 2017, at the Pwn2Own competition, which is a hacking contest. If you’re able to hack the system, you can not only own that system and take it home, but you’re also awarded some cash, as well.
For this particular VM escape, there were a number of exploits that were used. First, the bad guys started in the browser. They found a JavaScript engine bug in Microsoft Edge that allowed them to perform code execution in the Edge sandbox. That then gave them access to the Windows 10 kernel, and they took advantage of a bug in the Windows 10 kernel to compromise that guest operating system.
From there, they used a hardware simulation bug in the VMware hypervisor to then escape to the host. After this competition was over, all of these vulnerabilities were patched, so that no one could use these exact same exploits to escape the virtual machine.