Fighting off Microsoft Hyper-V security hacks

When it comes to IT security, there are those who feel the vendors have their best interests at heart and others who are more wary. With virtual environments, IT professionals have to come to terms with the fact that they are adding yet another layer to the potential attack surface. But while there will always be discoveries of new attack vectors, virtual environments are built for security.

In this case, we may be our own worst enemies. While the recesses of the malware community rely on known exploits, the most common malware attacks usually involve users taking action to compromise their own security. As administrators of virtual environments, we may be allowing that to happen with less than secure configurations.

Real world hypervisor exploits
If you think that virtual machine hacking is no more than a concept, take a look at the VMware breakout exploit (CVE-2009-1244) that debuted in 2009. The hack allowed an attacker of a virtual or guest machine to break out of the built-in confines of that virtual instance and gain control of the host machine. Although it was patched quickly, it was still an available exploit.

Another well-known hack involved a service attack on an un-patched Windows Server 2008 or R2 Hyper-V host from a guest virtual machine via the channels of the virtual bus. Microsoft patched this vulnerability in security bulletin MS 10-102.

Important configuration considerations for Hyper-V
Although many IT departments take patching servers very seriously, patching a virtual host can be a pain. Taking all of your virtual machines offline or even moving them to another Hyper-V cluster member can be time consuming and -- as I’ve often found -- impossible when resources are overcommitted. Treating the hypervisor as a piece of hardware may provide short-term stability, but in reality it creates a potential security hole, so patching this layer is critical.

Exploits and up-to-date patching are an obvious concern, but at the moment they may be the least of your worries since true code exploits to the hypervisor are still relatively uncommon. Admins often assume a certain level of security or segregation in virtualization that may not exist, and might ignore warnings and best practices in order to ease the daily grind of virtual machine administration. These bad choices are often forgotten soon after they are made, however, and you won’t realize those mistakes until there is an attack on your systems.

Putting the focus on Microsoft Hyper-V, there are some key moves to make during the initial setup that will help reduce your attack vector. First is the setup of your virtual networks. The hypervisor hosts virtual Ethernet switches that can be utilized and connected in various ways to connect to the physical layer using the network card in your parent host. With a misconfiguration, these virtual connections can potentially lead to several issues.

If you share your management network with your guest VMs, the attack vector allows a VM to access the Hyper-V management operating system and, with the right credentials, access the Hyper-V host and settings or other virtual machines. This option is turned off by default, but too many admins switch it on because of the ease of administration from many machines or limited availability of network interface cards (NICs). Enabling this setting is a security threat because you can attack the management OS from every virtual machine it hosts. Therefore, always devote a physical network adapter to a dedicated management network and never share those NICs with normal VM traffic.

You can also configure Hyper-V to recognize VLANs in order to logically separate the traffic coming from the various machines. While this is a wonderful method to mix and match various subnets onto a single machine and support clustered hosts without concern for the physical layer, you’re not really increasing security. It may appear that way on the surface since virtual machines on separate VLANs cannot see each other’s traffic without access and proper routing at the network layer. In reality, however, those bits are all on the same virtual and physical wire making VLAN hacking possible. As such, the rules one would take in the physical world also apply to the virtual world.

This leads to my next point: do not mix servers that have different security requirements onto a single virtual host. Every server should have some sort of basic security level as determined by you or your IT department. For example, a Web server in a demilitarized zone (DMZ) would have different security than an internal file server. If you label that Internet-facing DMZ Web server as having a higher risk of exploitation than your internal file server then you should not allow those servers to exist on the same virtual host, nor should you allow those two networks into the same virtual host. This is another case where physical security rules also apply to the virtual world.

When running Microsoft Hyper-V, nothing else should be running on that host except Hyper-V. All too often an admin will take an existing server and install the Hyper-V role in order to gain additional use of that physical server. That idea is fine, but you cannot allow any other server function to continue to exist on the host. Instead, move the application to a virtual machine. An exploit in application code, which is often harder to track and patch in most environments, could allow access into the host machine, which would then lead to all of the guest virtual machines.

One other piece of advice is to have an account or group for virtual machine administration that is separate from what you have for your virtual hosts. If an exploit does occur, you don’t want to give away the keys to the virtual kingdom. Also, for the best possible auditing, ensure that Integration Services is installed on all of your virtual machines.

Microsoft Hyper-V includes many features to protect your systems, such as address space layout randomization (ASLR), the process for the virtual processors running in user mode and each VM owning virtual devices and VM buses. Oftentimes, the biggest concern is not with the hypervisor itself, but with access to overly-privileged configurations or exploits to other applications. Use best practice to keep your patches updated and networks separate to avoid the more severe threats to your virtual environment.

You can follow SearchWindowsServer.com on Twitter @WindowsTT.

ABOUT THE AUTHOR
Eric Beehler has been working in the IT industry since the mid-90's, and has been playing with computer technology well before that. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.