Securing virtual servers

Every organization is going for virtualization. The main reason being cost cutting and to ensure maximum utilization of hardware resources. Virtualization has revolutionized the data centre and is one of the key foundational technologies underlying cloud computing. This has made Several companies rushing frantically into deploying virtualization solutions both in their private and public clouds, without taking into account the risks involved.  But when organizations are going virtualization, the technology has got its own inherent vulnerabilities.

 The clouds have their unique problems in protecting virtual assets can be more difficult than protecting physical servers; ultimately, there is no virtualization technology that can equal the protection of physical separation. Yet the same concepts apply in the virtual world as the physical world:  Hardened configurations, patch management, network security and monitoring all have a role.  It’s also critically important that anyone managing a virtual environment be aware of the evolving threat landscape targeting virtual infrastructure.  This is no different than the familiar risk management processes done to protect operating systems running on physical servers.

Statistics show steady growth of threats targeting the clouds; this is a cause of worry for IT specialists who use the same mode of deployment in physical machines.  Attacking a single physical host could possibly give the attacker access to confidential data stored in many different virtual servers.  This task becomes even easier for the attacker as servers are migrated from behind a private firewall into cloud-based virtual hosts that are accessible from the Internet.

What are the common vulnerabilities in virtualization?

 a)       VM Sprawl[1]“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 VM Change Management – a formal review process for VM security before deployment and/or  An authorized set of VM templates, then VM deployments can get out of control which is commonly known as “VM Sprawl”.” Vaidya (2009)

“This has led to VM sprawl, which is the unplanned proliferation of VMs. Attackers can take advantage of poorly monitored resources. More deployments also mean more failure points, so sprawl can cause problems even if no malice is involved.” pentestlab.wordpress.com (2013).

According to a Jun’08 survey by InformationWeek, only 20% of Enterprises surveyed had a formal review process in place with security of VMs in mind. VMSprawl is one of the biggest problems in Enterprise deployments of Virtualization.

 b)       Hyperjacking[2] “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 rouge 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 Virtualization specific Vulnerabilities and Threats 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 & others, 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.” Vaidya (2009).

c)        VM Escape – this is the process of breaking out and interacting with the hypervisor or VM Host.[3] “This gives the attacker access to all VMs and, if guest privileges are high enough, the host machine as well. ” pentestlab.wordpress.com (2013).

d)       Incorrect VM Isolation[4]“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.” Vaidya (2009)

e)        Denial of Service – This is whereby the hypervisor is targeted with traffic it can be able to handle making it not available to genuine users. “The availability of botnets continues to make it easier for attackers to carry out campaigns against specific servers and applications with the goal of derailing the target’s online services.” pentestlab.wordpress.com (2013).

f)        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.” pentestlab.wordpress.com (2013).

g)       Unsecured VM migration[5]“This occurs when a VM is migrated to a new host, and security policies and configuration are not updated to reflect the change. Potentially, the host and other guests could become more vulnerable. Attackers have an advantage in that administrators are likely unaware of having introduced weaknesses and will not be on alert.” pentestlab.wordpress.com (2013).  Vaidya (2009) states that 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).

h)       [6]Host & Guest network Communication Vulnerabilities – Applications such as email-clients and web-browsers that communicate over the network, are prone to programming flaws that could result in exploitable security vulnerabilities. Most common form of application exploits are typically the Trojan horses and malicious codes such as viruses that are sent through the application data. These vulnerabilities could range from being harmless to extremely dangerous. The network protocol stack, such as TCP/IP used in Internet communication, facilitates communication over the network. Although compliance with rigorous standards is mandatory, different implementations of TCP/IP stacks have been known to have flaws in them. Some vulnerability is inherent to the TCP/IP protocol standards themselves while others are specific to specific implementations. No matter where it lies, since the protocol stack gets the network data first and since it runs in the OS kernel-space, exploitable vulnerabilities within the stack are fairly dangerous for the VM & Hypervisor security.” Vaidya (2009)

How to protect VM ware deployments

a)       VM-Specific Traffic Isolation[7]“Since virtualization servers always have an internal network switch to route the traffic between VMs, that traffic is never visible to the outside network. These internal switches are soft switches like VMWare’s Virtual Switch or XenBridge in XenServer, handle packets in VM-to-VM and VM-to-Network traffic. Controlling this VM-to-Vm traffic which is invisible to the outside network is essential since if one VM gets compromised it can potentially comnpromise rest of the VMs and even the virtual server through this internal network. Thus Implementing a Firewall to provide network traffic & access control is a requirement in most Enterprise deployments and for regulation compliance such as PCI DSS where it explicitly calls for a “firewall at each Internet connection and between any DMZ and the internal network zone”. Ensuring that the VM traffic is isolated is also a necessary step to protect regulation protected data & information. These controls include that,

  • Only intended services and protocol are allowed to and from each virtual machine;
  • Regulation compliance virtual machines have a very limited and restricted access to and from non-compliant virtual machines especially if they are running on the same server or IP subnet
  • Data exchange between virtual machines is properly guarded
  • Use VLAN for network segmentation wherever possible
  • Management vNIC and production vNIC are kept separate on each VM and possibly connect on different physical NIC or at least on separate VLANs
  • Any test network interfaces are dynamically & automatically removed from the VM if it has a production network vNIC

One way to enforce these best practices for VM traffic isolation is to use either the virtual security appliance which has traffic isolation and firewalling capabilities. However not all VSAs are created equal and one must ensure that they provide capabilities to satisfy all of the above enforcement points including VLAN enforcement and NIC isolation.” Vaidya (2009).

b)       Administrative control –[8] “Secure access can become compromised due to VM sprawl and other issues.Ensure that authentication procedures, identity management, and logging are ironclad.” pentestlab.wordpress.com (2013).

c)        Customer security – “Outside of the VM, make sure protection is in place for customer-facing interfaces such as websites.” pentestlab.wordpress.com (2013).

d)       Server-Specific Traffic Isolation –[9] “Virtualization Servers typically have an OS-based access point in to the hypervisor configuration & management. In VMWare ESX it’s called the service console, for Microsoft Hyper-V it’s the parent partition and for Citrix XenServers it’s the Domain 0 or dom0. These virtualization servers typically require two or more virtual network connections used internally for different purposes ranging from console access for management, for access to shared data-stores or for virtual machine migrations. Network segregation or isolation of all management control networks such networks on which administrative (i.e. not production) interfaces are situated is a necessary step for enterprise enforcement. Since the easiest way to compromise a system is to re-configure it to bypass implemented security measures, it is critical that these administrative interfaces are protected by multiple layers. For security enforcement, restricting access to the console or management network is crucial in p providing server isolation. Enforcement can occur at two levels of management network access. The first one is at a user-credential level which typically is managed through the vendor-specific management software such vCenter from VMWare or Citrix Essentials from Citrix. The second one is through the network access control. Here an admin can set up which IP addresses (clients) are allowed access to the console. This is a simple but very effective way of restricting access, especially if the management is done through a separate management NICs, essentially rendering console access unavailable to routed IP addresses. ACLs are easy to configure and manage. If servers are deployed in clusters or domains then ACLs can be deployed accordingly.” Vaidya (2009).

 


[1] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[2] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[3] Penetration Testing Lab,2013″ Common Virtualization Vulnerabilities and How to Mitigate Risks” http://pentestlab.wordpress.com/, Available at: http://pentestlab.wordpress.com/contact-the-lab/. (Accessed on August 27, 2013 @1105 hrs.)

[4] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[5] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[6] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[7] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

[8] Penetration Testing Lab,2013″ Common Virtualization Vulnerabilities and How to Mitigate Risks” http://pentestlab.wordpress.com/, Available at: http://pentestlab.wordpress.com/contact-the-lab/. (Accessed on August 27, 2013 @1105 hrs.)

[9] Vimal Vaidya. ” Virtualization Vulnerabilities and Threats: A Solution White Paper” RedCannon Security, Inc.Available at: http://www.redcannon.com/new/vDefense.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s