This week I wrote an article for a few of our partners, include the well-known SpiceWorks IT pro forum. If you’re interesting in learning about the additional risks introduced by hardware vritualization and in securing your virtual environment, read on.
Spinning up a virtual machine (VM) without a good security policy, a hardened hypervisor, and virtual security controls is like diving into a public pool with your mouth wide open—you may not contract a disease immediately, but eventually you’ll have a very bad day.
I’m not sure why some administrators forget to harden their virtual environment. Perhaps they imagine it like the virtual realm of “World of Warcraft“; if a VM gets pwned they can just return, ghost-like, and resurrect it. Personally, I think it’s more like the “Tron” universe; if data on your VM gets popped, it disappears “IRL” too. This article discusses the additional security risks hardware virtualization introduces, and shares a few quick virtual security best practices to mitigate those risks.
A brief history of virtualization
The concept of virtualization has existed since the inception of computing. Back in the mainframe days, and again when personal computers emerged, we virtualized our computers’ input/output (I/O) system via the operating system (OS). The OS (also called the supervisor) abstracts I/O functions so individual applications don’t have to “re-invent the wheel” and figure out how to handle them.
Next, we wanted to run many programs at once, so we virtualized memory. Multi-tasking OSs like Windows present virtual memory pages to each application. Every application thinks it has all your computer’s memory resources, but your OS secretly virtualizes it.
Finally, we come to virtualization as we know it today; specifically, hardware virtualization. Hardware virtualization allows us to abstract our computer’s hardware and run multiple OSs on one physical machine. In order to do this, hardware virtualization requires an additional authority to manage everything, called the hypervisor.
Hardware virtualization presents many benefits, most of which you’re probably aware of. It saves us time, money, space, HVAC costs, and may even help us go green. So why hasn’t everyone virtualized everything? While there is no simple answer to that question, security is one major inhibitor.
Virtual environments increase real-world risks
Hardware virtualization introduces new security risks and concerns. I’ve heard people generalize this risk as, “the same security issues as physical computers, just on virtual ones.” There’s some truth to that, but hardware virtualization also adds additional layers of concern. Let me share a few of those issues:
- Hypervisor security issues – I mentioned the hypervisor — the higher-level authority that abstracts your computer’s hardware, and manages multiple VMs. A hypervisor is just software, albeit complex software. Like all software, it can suffer from development bugs (buffer overflows and the like), which may result in security vulnerabilities. The hypervisor is a high-privileged system, so vulnerabilities in its software pose dire consequences. Hypervisors also introduce new management interfaces and services to your infrastructure, both of which present new targets for attackers. In short, hardware virtualization increases the potential attack surface of your network.
- Multi-tenant security issues – Running multiple computers on one physical platform introduces new problems. Information security has the concept of security domains. You segment resources by what they do, and how much you trust them. In the physical world, servers typically do one thing, so separating them is easy. In the virtual world, you can place many servers on one machine, making it more difficult to separate them by domain. Furthermore, VMs can communicate instantly with one another, sans a physical network. This leads to the “bad neighbor” syndrome, where one infected VM can quickly infect others on the same hardware, if configured improperly. Multi-tenancy also introduces data remnant risks, where one VM might access the data left in memory by another VM.
- Virtual network blind spot – I mentioned VMs can communicate with each other over a virtual network, never hitting a physical network. Though we have many great physical network visibility and security tools, they can’t see anything happening on virtual networks. Unless you implement virtual security controls, you won’t see the attacks until it’s too late.
- It’s relatively new and complex – While virtualization (even hardware virtualization) has been around for decades, many small business administrators only dove into it recently. Some of us are just starting to wrap our heads around virtual networking and switching, let alone learning how to harden hypervisors and implement virtual security controls. Additionally, some virtualization benefits complicate security. Its increased flexibility and mobility means you can copy and paste a VM instantly, but also allows you to quickly replicate, multiple, and further expose security mis-configurations. In short, virtual servers often move quicker than security policies can keep up.
Those are just a few unique virtualization security concerns. VMs also suffer from “normal” computer security risks too – only these risks are further complicated by the liquid nature of virtual environments.
Virtual attacks: From theory to reality
You might ask, “Well that sounds scary in theory, but are attackers really targeting virtualization?” In a word, yes.
For instance, security researchers have demonstrated virtualization rootkits (Blue Pill), attackers have designed malware that avoids researcher VMs, and criminals have leveraged VMs as Command and Control (C&C) channels for botnets. Most recently, the Crisis malware included a spreading mechanism that searched for and infected virtual images, making it the first wild malware that specifically targets VMs.
Security best practices for a virtual world
At this point, you might be balking at the idea of virtualizing anything, but don’t worry. Virtualization’s benefits far outweigh its risks, and there are defenses for all these dangers. Here are a few virtualization best practices to get you started:
- Favor bare metal hypervisors over hosted ones – Without going into full detail, there are two types of hypervisors: those that run directly on hardware (Type 1), and those that run on top of an OS (Type 2). I recommend using a Type1 (or bare metal) hypervisor like VMware ESXi; the benefit being that it limits the scope of hypervisor attacks. For instance, an elevation of privilege attack against a Type 2 hypervisor may give an attacker full control of your native OS, whereas there is no OS to access on a Type 1 hypervisor.
- Segment your hypervisor’s management network – Hypervisors have management interfaces which you can access over a network. Make sure to separate this management network from other virtual and physical networks you don’t trust, and limit access to management interfaces.
- Disable unnecessary hypervisor services – Hypervisors provide many services to virtual machines, including access to USB devices, Bluetooth, disc drives, file services, physical network cards, and so on. They also provide ease-of-use features, like the ability to drag and drop files between virtual machines. Each of these services exposes more attack surface. If you don’t use it, disable it.
- Patch your hypervisor regularly – It’s software; it has vulnerabilities; patch it. Hypervisors fall into the class of things people tend to deploy and forget. Don’t let that be the case for you.
- Apply least privilege principles to hypervisors and guest VMs – You already know the least privilege principle, now extend it to your virtual environment. Who can manage the hypervisor, build new VMs, launch VMs, and what privileges do users on guest VMs have? These are all things you can control.
- Standardize your VM images – VMs move fast. People clone, copy, and redeploy them at the speed of file transfer. Badly configured VMs can spread security mis-configurations quickly. On the same token, creating a well-hardened, properly configured VM to use as a base image ensures your newly deployed virtual servers will at least start with secure defaults.
- Deploy virtual security controls – Today, virtual networks are a huge blind spot in our infrastructure. Though hypervisor vendors have started to provide some basic virtual security controls, they lack high-end security and visibility tools. Some third parties, like WatchGuard, have started to provide these virtual security solutions. Consider using them.
- Extend normal security controls to VMs – The tips above help you specifically harden your virtual environment, but virtual machines still act like normal computers. They need OS and software patches, as well as normal host-based security controls like antivirus (AV). Luckily, there are solutions which help you apply such controls across multiple virtual machines at once.
At the end of the day, all the information and network security practices we use to protect physical devices still apply to protecting the virtual ones. The only difference is we have to extend these practices across new surfaces, and introduce our familiar tools to new environments. Once you understand the new attack surface that hypervisors and virtual networks present, you can start to mitigate these risks using familiar defenses. It’s just a matter of diligently doing what you already know. — Corey Nachreiner, CISSP (@SecAdept)
August 31, 2012 
I think this is a pretty big deal in malware evolution. Unlike physical computers, virtual images get cloned, copied, and shared quite a bit. Often, IT administrators have pre-set virtual images they use as the base image whenever building a new virtual machine. If one of these base images got infected, you could inadvertently spread that infection to every new virtual image you spun up.
WatchGuard Security Center 