Thursday, April 17, 2014

[infosecinstitute] Virtualization and Cloud Computing

In cloud computing, there are a number of components used to build the cloud infrastructure. At the lowest layer there are actual hardware components like servers, network attached storage and network components. In order to limit the possibility of spreading an infection, networks need be properly separated into multiple DMZs with limiting rules of connectivity between two networks. The very core of cloud computing is virtualization, which is used to separate a single physical machine into multiple virtual machines in a cost-effective way. Don’t get me wrong, running and operating a cloud is certainly possible without virtualization, but requires more work and time to actually pull it off; by using virtualization, we’re basically getting a lot of the work done for free. With virtualization, a number of virtual machines can run on the same physical computer, which makes it cost-effective, since part of the physical server resources can also be leased to other tenants. Such virtual machines are also highly portable, since they can be moved from one physical server to the other in a manner of seconds and without downtime; new virtual machines can also be easily created. Another benefit of using virtualization is the location of virtual machines in a data center – it doesn’t matter where the data center is located and the virtual machine can also be copied between the data centers with ease.

While the main benefit of virtualization is cost-effectiveness, customization increases the cost of such an environment with an advantage of increased security. If we customize the cloud virtualized environments too much, the costs go up considerably. There are three basic cloud computing service models: SaaS, PaaS and Iaas, and three basic cloud computing deployment models: public, community and private. When choosing the right combination we would like to use in our services, we need to be aware that by having greater control over the cloud, there also exists the possibility of increasing the security of the cloud. We can increase security of the IaaS service model as compared to SaaS, because we have greater control over it – the same is true for deployment models: we can increase security of a private cloud as compared to a public cloud. In the previous article we discussed which parts of the cloud infrastructure a tenant has access to; keep in mind that whatever isn’t directly controlled by a tenant, it must be administered by the CSP. When working with a public cloud, it’s the CSP’s job to properly secure every aspect of the cloud infrastructure, since the tenant usually doesn’t have access to it, but in a private cloud we have to take care of those implications by ourselves.
Traditional vs Virtualized Environments
In virtualized environments there are number of items we should not overlook when security is high on our priority list. In a traditional IT environment, the network and physical servers as well as network equipment are operating on their own. In a traditional network environment, when we talk about a network switch, we mean the physical network switch we can see and touch, whereas in virtualized environments practically everything can be virtualized nowadays.
  • Network Segregation: the most simple virtualized environments would use only one network where all virtual machines would reside, but that wouldn’t be very secure. In order to secure the network, the networking layer needs to be segregated into different DMZs, which heightens the security. For companies striving toward increased security, their own DMZ can be created where only their virtual machines would reside. We can go even further and request separate networking equipment such as switches from our CSP, where only traffic destined for our own virtual machines would flow through it. We can request the CSP to use VLAN tagging/trunking for our virtual machines, which implements virtual LANs – this means that every packet destined to and coming from our own virtual machines will have a certain VLAN ID, so only network interfaces in the same VLAN will be able to receive and process network packets.
  • Physical Server Segregation: when leasing a virtualized environment, our virtual machines usually reside in a common physical server with virtual machines of other tenants as well. If we lease the entire physical server, which will be used to run only our own virtual machines, we’re increasing its security, since the virtual machines of other tenants will reside elsewhere. Virtualization by itself provides another layer of defense against attackers, since each and every virtual machine is isolated from the rest of virtual machines. Therefore, if an attacker is able to compromise the virtual machine, he’s operating in a sandboxed environment. Even more, virtualizaton also provides an easy way to save the tainted copy of the virtual machine for later forensic analysis.
  • Data Storage Segregation: with every virtual machine there also comes a storage for storing data, which usually resides in an external centralized data storage server. To connect with the storage data server, virtualization software uses different protocols operating over the network. Therefore, the data belonging to each virtual machine is written to the same hard drive accessible over the network. In order to improve security, we can lease our own data storage server from the CSP to store the data on our own storage. When data of multiple virtual machines is stored on a centralized data server, there’s a chance that one virtual machine might be able to access the data of another virtual machine. To avoid this issue, we can always encrypt the data that we’re storing in a data store, so even if another virtual machine can read our data, it will be garbled.
Security Concerns when using Virtualization in Cloud Computing
Virtualization provides many benefits when used in a cloud computing platform, such as cost-efficiency, increased uptime, improved disaster recovery, application isolations [1], etc. Despite all the advantages, when virtualization is used there are also a number of security concerns outlined below.
  • The Hypervisor: the hypervisor is used to separate operating systems of virtual machines from the physical hardware. When we add a new virtual machine on top of the same physical machine, we must ensure that the operating system has the latest security updates installed and the software has been properly patched. Once the attacker has gained administrative access to the guest operating system, he can further advance to exploiting the vulnerabilities that exist in a hypervisor – by successfully exploiting such a vulnerability, the attacker can gain complete access to the host physical machine. Even more, once the attacker has access to the host hypervisor, he can easily access all the virtual machines running on that physical machine. In order to understand the importance of having a secure hypervisor, we must first say a few words about it. A hypervisor was specifically built for virtualization in mind and has therefore a required limited function specific to the hypervisor. It doesn’t need to be as complete as a whole operating system, because it must be able to perform a limited set of functions; therefore it also has a smaller number of entry points that can be attacked and exploited. The concerns are great, since hypervisors are rarely updated and therefore a new security vulnerability would most likely be unpatched for a long period of time. In 2006 two rootkits were developed to demonstrate how a rootkit can be used to take control over the host machine – hypervisor and all of its virtual machines: Blue Pill in Sub Virt [2,3].
  • Resource Allocation: when a certain resource, like data storage or physical memory, is allocated to a virtual machine, the virtual machine can use it for storing its data. If the resources are later reallocated to another virtual machine due to this virtual machine not being needed anymore and is therefore removed, the new virtual machine could read the data from hard drive or memory. The data on such resources must be properly deleted when being transitioned from one virtual machine to the next.
  • Virtual Machine Attacks: if an attacker can successful gain access to one virtual machine by exploiting a vulnerability in one of the applications running in that virtual machine, he can attack other applications running in different virtual machines over the network. If the virtual machine is running on the same physical host as the compromised virtual machine, it may be hard to detect such network attacks. We must be able to monitor the traffic coming to and from each virtual machine on the same physical host.
  • Migration Attacks: when we migrate a virtual machine, the migration usually consists of transferring the whole virtual machine over the network from one physical machine to the other. For a successful attack, the attacker already needs to have access to the network where the migrations are taking place and reading/writing into memory at the time of migration. When the migration communication is not encrypted, the attacker can perform a MITM attack to copy the whole virtual machine VHD file.
Mitigation of Security Concerns
The items below describe how we can mitigate the security concerns we outlined previously.
  • The Hypervisor: attacks on the hypervisor can easily be prevented by regularly updating it. Since there is a low number of vulnerabilities in the hypervisor itself, there is also a low number of times we will have to update, but it’s important that we do. This will not protect against zero-day vulnerabilities that may still be present in a hypervisor, but at least we’re protected from known vulnerabilities that exist in the wild.
  • Resource Allocation: prior to allocating resources to new virtual machine, the resources need to be properly protected. When assigning the physical memory to a new virtual machine, the memory needs to be filled with zeros in order to prevent any data used in the previous virtual machine from being leaked. The same is true for hard drive data, which might still be present even after easing and recreating the partition. A new virtual machine can use different forensic tools to read the whole unstructured contents of the hard drive into the file and analyze it for possible leaked data. To prevent this, we must also overwrite the hard drive used by the old partition with zeros when assigning it to the new virtual machine.
  • Virtual Machine Attacks: we must ensure that the underlying virtualization software can differentiate against traffic coming from and going to different virtual machines. The traffic also needs to be analyzed for possible known attacks; one way of doing this is by using port mirroring to copy any traffic on a specific port on a switch to another port (mirroring) for data to be analyzed by IDS/IPS.
  • Migration Attacks: migration attacks can be handled by using proper mechanisms for detecting and preventing MITM attacks. To enhance security, the migrations should also be done over a secure communication channel like TLS.
Conclusion
In this article we’ve seen how a virtualized environment is used in cloud-based applications. We compared it to a traditional environment and presented the concerns that come with it. We specifically addressed the hypervisor attacks where a vulnerability in hypervisor itself is exploited to gain access to the underlying host. There’s also a risk of data leakage through resource allocation, where a new virtual machine can read the data from physical memory or hard drive of the previous virtual machine. There’s also a possibility of one compromised virtual machine to attack the other virtual machine running on the same physical host without being discovered for longer periods of time. We also discussed a way to copy a whole virtual hard disk by doing a man-in-the-middle attack when a migration is in place.
At the end of the article we presented how we can protect ourselves against previously mentioned security related concerns. I should emphasize that securing the virtualized environments is not impossible, we just need to be aware of the security concerns and take the time to address them properly. Once the mitigations are in place we should also take the time to test them to make sure that we are indeed secure against known threats.
References:
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)