Quadra

Connecting Technology and Business.

VM Security Vulnerabilities

While Hypervisors are considered better secured than general-purpose OSes, Virtualization does introduce a new & potentially devastating threat-matrix in an enterprise environment. Here are some of the virtualization specific threats & vulnerabilities that IT & security administrators should be aware of before deploying virtualization environments.

 

 
• VM Sprawl:
VM Sprawl refers to uncontrolled deployment of VMs in an Enterprise environment. It is a simple, short & quick process to deploy new VMs on existing VM severs hence if an Enterprise doesn’t have authorization policies around
a) VM Change Management;
b) a formal review process for VM security before deployment and/or
c) an authorized set of VM templates
then VM deployments can get out of control which is commonly known as “VM Sprawl”. VM Sprawl is one of the biggest problems in Enterprise deployments of Virtualization.
 
• Hyperjacking:
Hyperjacking is a term used for an attack which takes control over the Hypervisor that creates the virtual environment within a VM Host. Since Hypervisors run beneath the Host OS, if installed, a rogue hypervisor can take complete control of the virtualization server, all the guest VMs within the virtualized environment and possibly the Host OS as well. So far Hyperjacking vulnerabilities are mostly specific to Type-2 Hypervisors. However, Hyperjacking of the service console or Dom0 on Type-1 hypervisors is possible which in essence would allow the attacked unlimited access in the entire virtualization server. Regular security measures such as Endpoint firewalls, IDS/IPS, Anti-Virus etc are ineffective & defense-less against Hyperjacking since security solutions in VM or server are not even aware that the host machine has been compromised. Though largely theoretically at this point, it’s a critical threat to the security of every virtualized environment.
 
• VM Escape:
Normally virtual machines are encapsulated, isolated environments. The operating systems running inside the virtual machine shouldn’t know that they are virtualized, and there should be no way to break out of the virtual machine and alter the parent hypervisor. The process of breaking out and interacting with the hypervisor or VM Host is called a “VM escape”.
 
• Incorrect VM Isolation:
VM Isolation is a critical aspect of keeping virtualized environment safe. Just like with Physical machines and Physical firewalls, virtual machines should be restricted in communication from one-to-another. Incorrect VM Isolation can result in problems as simple as reduced virtualization performance (one VM constantly communicating to another reduces local resource usage for more important tasks) to denial-of-service and VM take-over.
 

 

 • Denial of Service:
Several types of denial of service exploits & vulnerabilities have been discovered in various types of hypervisors from different vendors. These potential DoS vulnerabilities range from traditional network based attacks or remote DoS to bring the Host or a specific Guest OS down; all the way to more exotic types of denial of service such as the ones which exploit hypervisor or virtualization tool & backdoor communications.

 

 
• VM Poaching (or Resource Hogging):
VM Poaching occurs when one VM Guest OS takes up more CPU or other resources allocated to it against the other Guest OS running in the same virtualized environment. A run-away VM can completely consume the hypervisor, thus starving rest of the VMs running within the hypervisor. VM poaching can occur with any of the hypervisor resources including memory, CPU, network and/or disk.
 
• Unsecured VM Migration: (VMotion)
When a VM is moved from one VMHost to another, the security policies & tools set up on the new VMHost need to be updated with moved VM so that same security policies for that VM can be enforced on the new VM Host as well. The dynamic natures of “VM Migration” could potentially open up security risks and exposure for not only the “migrated VM” but also for the new VMHost & other Guests running on that VM Host.
-      From a Whitepaper from RedCannon Security Inc.
Loading