149. Virtual Machine Attacks (OBJ 3.5)
In this lesson, we’re going to discuss virtual machine attacks, including VM escapes, VM hopping, sandbox escapes and other VM concerns. First, we have VM escapes or virtual machine escapes. A VM escape is a type of attack where a threat actor attempts to get out of an isolated virtual machine and then send commands directly to the underlying hypervisor. Because each virtual machine is supposed to be isolated, performing a VM escape should be very difficult to accomplish. After all, each guest operating system shouldn’t even know itself that it’s part of a virtual machine because it still thinks it has full access to the emulated physical machine that the hypervisor is providing. For a VM escape to be effective, the attacker has to find a way to directly interface with the underlying physical resources, such as the physical servers memory, hard drive, or processing. This usually occurs by exploiting a vulnerability in the hypervisor’s code itself. There have been a few instances of this occurring. And patches have been developed and released by manufacturers as soon as they discover these vulnerabilities. VM escape is easier to perform on a type two hypervisor than it is on a type one hypervisor. If you’re using a type two or hosted hypervisor, the attacker might be able to gain access to the underlying operating system that’s actually hosting your virtual machines.
If they can, they can then be able to escalate their privileges and access other virtual machines being hosted on that same device and, in effect, create a virtual machine escape. To prevent a virtual machine escape, it’s always important to ensure that your guest operating system, your host operating system, and your hypervisor all remain patched and up to date. Second, we have VM hopping or virtual machine hopping. Now VM hopping is a type of attack when a threat actor attempts to move from one virtual machine to another on the same host. A VM hopping attack is going to focus on exploiting the hypervisor of the virtualization software or some kind of a feature to move between the two supposedly isolated virtual machines. Now VM hopping sounds similar to a VM escape, but there is one key difference. That VM hopping is now focused on moving between one virtual machine to the other, whereas when we talked about VM escape, it’s focused on reaching the underlying hypervisor or host operating system. To protect against VM hopping, you should always ensure your hypervisor is up to date and properly patched. Also, you need to ensure your guest operating systems and the hypervisor are securely configured using a best practice configuration guide to ensure there is no erroneous connections between the virtual machines that should have been isolated. Third, we have a sandbox escape. Now a sandbox is a security mechanism that’s used to separate running processes and programs in an effort to mitigate system failures or software vulnerabilities from spreading.
Most commonly, sandboxes are created using virtual machines or containerization. Web browsers, for example, are commonly using the concept of sandboxing to separate running web code from the protected operating system or other software on the system. Now a sandbox escape will occur when an attacker’s able to circumvent the sandbox protections in order to gain access to the protected operating system or other privileged processes. To protect your systems from a sandbox escape, it is important to ensure your software and operating systems remain patched and up to date, as well as ensuring that you have strong endpoint protection software installed on your client and that you limit the extensions or add-ons that are installed inside your web browsers in the case of protecting against web browser sandbox escapes. Fourth, we have a few concerns that we need to talk about as well when we think about virtual machines and virtualized environments. This includes things like migrations and data remnants. Now, one of the major benefits of using a virtual environment is that you can migrate a virtual machine from one host to another, even while it’s running.
This is called a live migration. Now, this migration occurs over the network, so it’s important to always ensure that the migration only occurs over a trusted network or one that utilizes proper encryption between the server setting the virtual machine and the server receiving that virtual machine. If the live migration occurs over an unencrypted connection, though, there’s going to be a possibility that the data contained within that virtual machine could be exposed to prying eyes or have its integrity compromised by an attacker using an on-path attack. To prevent this, virtual machine images should be encrypted prior to being sent from one server to another over the network. Remember, servers are no longer just physical devices located inside of our data centers. But they’re also virtual machines that are simply a file located on some kind of a file system. And these files can be stolen by an attacker. Another major concern when utilizing virtual machines in a cloud environment is data remnants that could be left over when you deprovision excess virtual servers. Many cloud providers utilize block storage that could allow data that is no longer needed to be left behind on their storage devices. If it’s not properly erased, that data may be accessed by unauthorized users.
To mitigate this threat of data remnants, you should always encrypt your virtual machine storage locations and ensure the encryption key is destroyed whenever the virtual machine is no longer needed and becomes deprovisioned. Another vulnerability you can exploit as an attacker is VM sprawl. VM sprawl refers to creating virtual machines without proper change control procedures. And this can lead to a vulnerable environment because people are spinning up virtual servers and not keeping track of where they are. And so they’re not getting the patches or security updates that they should. Now, as an attacker, you can gain unauthorized access to one of these different virtual machines and then use that as a pivot point into the rest of the environment. Another area you can exploit as an attacker is the virtual machine repositories.
Now VM repositories are the place where all of those virtual machine images and templates are being stored to be used in orchestration as they’re spinning up additional cloud services. As an attacker, if you can go after one of those templates and you can embed something like malware or backdoor in it, anytime a new virtual machine is being generated, it’s going to be using that infected template, and you’re going to be able to propagate that throughout the entire organization and always have access to every single server that’s based on that template. As a cybersecurity professional and defender, though, you always want to make sure that the templates and images stored in your repository are digitally signed. So that way, you can tell if they’ve been modified by an attacker.
150. Containerization (OBJ 3.5)
The newest type of virtualization that’s becoming popular in our networks is known as container based virtualization, also known as containerization. This type of virtualization is much more focused on servers instead of the end user though. With this type of virtualization, the operating system Kernel is shared across multiple virtual machines. But the user space for each virtual machine is uniquely created and managed. Containerization is a type of virtualization that’s applied by a host operating system to provision an isolated execution environment for an application. Containerization is considered fairly secure because it enforces resource segmentation and separation at the operating system level. Now, containerization is commonly used with Linux servers. And some examples of this container based virtualization include things like Docker, Parallels Virtuozzo and OpenVZ project. Now, what does containerization really look like? Well, you have a piece of hardware, and then on top of that hardware, you have a host OS, usually Linux, and then you have a container manager, something like Kubernetes or Docker or something like that. Now this container manager is going to be used to create different containers that contain different applications.
In this case, I have three containers. I have the first environment, which is based on the Kernel of the host OS. In this example a Linux system that’s being used. And so we have container one running Linux and it contains some applications there. Now, container two can do the same thing, and container three can do the same thing. Since all three containers are sharing the same host operating system files, this takes a lot less resources than doing pure virtualization using virtual machines like we talked about in our virtualization lesson. If we instead used individual virtual machines, each one would need its own copy of an operating system. And that could be eight to 10 gigabytes for each one. But with containers, we can all share the same operating system. So it uses a lot less storage base, and it takes a lot less processing power. This is the real benefit of using something like a container from an operational perspective. Now, because these containers are logically isolated, they can’t actually interface with each other. If I wanted to have two containers talk, I actually have to connect them through a virtual network and do the right routing and switching to allow them to talk.
By default, they have no way of talking to each other, and this is a great thing from a security standpoint, because we have this segmentation. Now, here’s your big warning when it comes to dealing with containers. If an attacker compromises the host OS underneath, for example, that Linux operating system I was just discussing, guess what’s happening? Well, this attack now has access to all of the containers in their data, because that one operating system is used by all of the containers being hosted.
This is one of the biggest vulnerabilities when you use containers. I can have a container system that’s running 50 different servers right now, and each of these is running different servers and services using containerization. But if somebody is able to get to that one server underneath, that Linux operating system, they now have access to all 50 of those hosted servers and all of their data. Another risk to consider is how your containers and other virtual machines are actually going to be hosted. Once we begin to rely on virtualization and cloud computing, it becomes very important to recognize that our data might be hosted on the same physical server as another organization’s data.
By doing so, we introduce some vulnerabilities into the security of our systems. First, if the physical server crashes due to something one of the other organizations is doing, it can actually affect all of the organizations on that same server. Similarly, if one organization is not maintaining the security of their virtual environments that are being hosted on that physical server, there is a possibility, that an attacker can utilize that to the detriment of all the other organizations hosted on that same server. Just as there are concerns when interconnecting our networks with somebody else’s, there’s also concerns with hosting multiple organizations data on the same physical server.
It’s important for us to properly configure, manage and audit user access to the virtual machines that are being hosted on those servers. Also, we want to make sure we ensure that our virtual machines have the latest patches, antivirus, anti-malware and access control in place. In order to minimize the risk of having the physical servers resources being overwhelmed, it’s always a good idea to set up our virtual machines with proper failover, redundancy, and elasticity. By monitoring network performance and the physical servers resources, we should be able to balance the load across several physical machines instead of relying on just a single one.
Another vulnerability that might be exploited by an attacker is when we use the same type of hypervisor across all of our virtual machines. So for example, if our organization relies solely on VMware’s ESXi Hypervisor, and a new exploit is created for that hypervisor, well, an attacker could use that against all of our systems. So if it’s successful on one of our servers, they’re likely going to try it on the rest of our servers. And if all of servers use that same platform, in this case VMware’s ESXi, this vulnerability could be exploited across our entire organization. The challenge with this though, is that again, if we utilize multiple hypervisor platforms our support costs and our training requirements are also going to increase.
Most organizations for this reason, do choose to use a single platform, but at least they’re making a measured risk decision when they do that. To mitigate that risk, the organization should utilize proper configurations, ensure the hypervisor always remains patched and up to date, and only accessible through a secure management interface, as well as tightly controlling access control. Now, these are some of the things you must consider when you start faring out, if you’re going to virtualize your systems and migrate them to an on premise or cloud based solution. First, are you going to virtualize? If so, are you going to use traditional virtual machines or are you going to use containerization? What is the risk versus reward here? There’s a balancing act that you have to do. It’s a business decision and it’s also a cyber security decision. And so you’re going to have to measure these things and decide what is best to select for your organization and its particular use cases.
