In the early 2000’s virus writing was all the rage. Think of the massive virus outbreaks that took place. Millions of infected hosts. The Sober virus that infected 218 million machines in seven days. The MyDoom virus sent over 100 million virus-infected emails. The “I Love You” virus infected 55 million machines and collected their usernames and passwords. These attacks were about bragging rights, not money.
That’s so last decade. Virus writing is so passé. Following it, however, was the age of malware and phishing. This was monetary bound, and sought to phish the user/pass and actually use them. Western Union must have made a bazillion dollars as the fence for criminals and crooks worldwide.
There’s a bigger picture. As we’ve moved from local workstations and servers containing copious amounts of tasty private information and data, toward the cloud where all of that data sexiness lives behind the locked doors of the Cloud Providers, the game is changing.
There are new technical challenges.
The back end to the cloud is Virtual infrastructure. And if you think of a cake, there would be the pan which is the physical piece, or the hardware. Above that is a yummy bit called the hypervisor which is a software piece that governs the host machine. This is essentially the cake part, the soft mushy filler between the pan and the frosting. But it’s software. The hypervisor dictates the basic operation of the host machine. It’s the abstraction layer between physical hardware and virtual machines in any virtualized platform. And on top of that abstraction layer is the frosting, or the guest operating systems. These systems are the “Virtual Machines”.
Enough of the cake references. I’m getting hungry.
In my previous article I outlined the fact that going virtual adds simplicity for IT departments. It’s easier to provision servers, it’s easier to move servers, it’s easier to decommission servers. It’s easier to set up networks. It’s easier from a management perspective all around. But in order to attain this simplicity, we are adding complexity on the platform side (the hypervisor), and not enough complexity to the network side. (i.e., virtualization creates flat networks which out of the box virtualization creates.) So by creating simplicity in the management side, we need to add complexity by adding a hypervisor and add security back to a flat network. Segregation. Divide and conquer. Yin and Yang.
One element of this added complexity is hyperjacking. Still in its infancy, hyper-jacking revolves around the corporate world’s newfound enthusiasm for application, operating system and solution virtualization. Hyperjacking is a verb that describes the hypervisor stack jacking. Hyperjacking involves installing a rogue hypervisor that can take complete control of a server. Regular security measures are ineffective because the OS will not even be aware that the machine has been compromised. Sneaky sneaky.
Why? Or rather, how? Because the hypervisor actually runs underneath the operating system, making it a particular juicy target for nefarious types who want not only to own (or PWN to those in the know) the host servers in order to attack guest VMs, but also to maintain persistence. (Okay, they’ve gotten into your hypervisor and stolen your data but, they’d also like the ability to come back whenever they want to steal more data.) Hyper-jacking is a great way to not only compromise a server and steal some data, but also to maintain that persistence. Get control of the hypervisor and you control everything running on the machine. The hypervisor is the single point of failure in security and if you lose it, you lose the protection of sensitive information. This increases the degree of risk and exposure substantially.
Now, what we’ve seen are some lab-based examples of hyper-jacking-style threats. But not many are in the wild. Or rather, we haven’t identified anything in the wild yet. Whether or not this has actually taken place across a mass amount of VMs we don’t know. But some examples of hyper-jacking-style threats include a specific type of malware called virtual machine based root-kits.
For a hyperjacking attempt to succeed, an attacker would need a processor capable of doing hardware-assisted virtualization. So the best way to avoid hyper-jacking is to use hardware-rooted trust and secure launching of the hypervisor. This requires the technology to exist in the processor and chipsets themselves and offers trusted execution technology as well as a trusted platform modules to execute a trusted launch of a system from the hardware through the hypervisor.
Now many vendors have subscribed to a set of standards from the Trusted Computing Groups compliance of measured launch and root trusts. And with that, there are also several security vendors who are offering hypervisor security products that work by checking the integrity of the hypervisor while it’s still in motion.
To do this, the programs examine the hypervisors and program memory, as well as the registers inside the CPU, to see if there are any unknown program elements. Root-kits in the hypervisor hide by modifying certain registers of the CPU and relocating the hypervisor somewhere else. And in this case, the hypervisor integrity software locates this relocated hypervisor. The hypervisor integrity software does this without the hypervisor being aware that it’s taking place. Of course, adding hooks into the process for examining the hypervisor also makes me uncomfortable, but that’s a conversation for another day.
This is all software, and software has rules that can be bent. So while addressing risks associated with the hypervisor we must remember that the hypervisor and the guest operating systems it supports are software and as such, need to be patched and hardened. Period.
Now with that in mind, you’re probably wondering “Well, how can I harden my environment?” Well, there are risks with all, but at least you’re thinking about it. Proactive thinking vs. reactive. Well done. Let’s put some basic design features in your environment to mitigate your risks:
1. Like security? Well, keep the management of said hypervisor in a secure environment. This is more of a network design issue than anything. It’s not hypervisor related, but still something to be considered. Never connect your hypervisor management functions to a less secure environment, than the virtual instances. Don’t put your management function access in the DMZ. Although this sounds like a common sense thing, we’ve all heard horror stories. Don’t be the horror story.
2. Your guest operating systems should never have access to the hypervisor. Nor should they know about it. Guest operating systems should never know they’re virtual. And your hypervisor should never tell a guest OS that it’s hosted. Secret secret.
3. Embedded solutions are much safer. I know this is common sense to most. Operating system-based solutions are traditionally less secure because there are more moving parts. My father always said, “keep it simple, stupid.” Same deal. Embedded modules are more simple and functional, as well as easier to manage, maintain and secure.
Understanding the hypervisor risks is one step toward securing them. Although much of the hyper-jacking conversation has been theoretical, don’t set yourself up in a place where you could be compromised if some 0-day hypervisor attack pops up. Secure your hypervisor, secure your world. Or at least part of it.