Linux
This article is a follow-up to our earlier piece “How a Linux bug may affect Windows-based infrastructure”.
Virtual infrastructure may be largely Windows-based, as far as most of the virtual endpoints would (possibly) run on Windows, while the hypervisor may (and most likely would be) Linux-based. In this case it may be susceptible to attack via the vulnerable version of Bash (Shellshock, again).
Hypervisors can be attacked both from the outside, just like any other PC or a server, and from the inside – i.e. from the host running on that hypervisor. In the first case, attackers will have to identify it within the corporate network.
In the second case the sequence may look like this:
a) An attacker detects a Windows-based under-protected virtual machine – and takes it over using phishing or a watering-hole sort of attack (directed on user, of course).
b) Gaining the initial foothold, the attacker may attempt to use so-called “virtual machine escape” vulnerabilities (such as CVE-2008-0923, CVE-2009-1244, etc.) breaking out from the “isolated” VM and interacting with the host OS – i.e. hypervisor itself. This interaction may come in the form of a malicious attack exploiting the Shellshock flaw.
c) Gaining access to the hypervisor means gaining control over every other virtual machine running on the host. Because the hypervisor sits between the physical hardware and the guest operating system, an attacker will then be able to circumvent security controls on the virtual machine. On all of them, actually.
Multistage attacks may sound sophisticated, but there is nothing exotic about them. The fact that both Heartbleed and Shellshock are easy to exploit, further increase the risks of these scenarios becoming a reality.
As a matter of fact, vendors of virtualization solutions do consider such possibilities.
VMware
VMware acknowledged that certain products, namely ESX 4.0 and 4.1 have a vulnerable version of the Bash shell, and recommended installing patches. Patching a number of virtual appliances, such as vSphere Replication 5.8, those are running Linux is also recommended.
Details are available at this bulletin.
Xen
Citrix and Xen Project also acknowledged a possible vulnerability in XenServer:
“In deployments where the Citrix XenServer host is configured to use DHCP for the host IP address allocation, this issue could allow an attacker with access to the management network to compromise the Citrix XenServer host.”
More technical details are available at Xen’s bulletin as well as at Citrix’s support site article, both covering the Shellshock issue.
KVM
KVM is supposed to use Linux (Ubuntu, for instance) as the hypervisor OS, which also means a possible exploitability with Shellshock. To assure safety, Linux distributions used therein should be updated.
Oracle
In its special Shellshock-related security bulletin Oracle acknowledged that Oracle VM versions 2.2, 3.0, 3.1, 3.2, 3.3 are among products that require patches against the Shellshock vulnerability. Note that the bulletin had been last updated on October 21st, so it requires extra attention.
Microsoft Azure
This is a non-Linux solution, but still Bash may be present there. When asked about the possibility of exploitation, Bilal Alam, Microsoft’s Partner Development Manager, Azure Websites, wrote the following:
“Azure WebSites is safe with respect to ShellShock. Azure WebSites uses IIS as our web server and we do not expose any external anonymously-accessible endpoint which exposes/calls Bash.
Note that we do install Bash as part of our VM installation (it comes with Git). But we do not expose any vector for calling into this shell remote/anonymously. We will be updating Bash for caution-sake.”
Again, particular attention to a hypervisor is required. Recently a fellow IT worker told us about a situation they had to deal with: a hypervisor failure (apparently a hardware problem) led to the crash of an entire park of virtual machines. It wasn’t related to Shellshock, and most likely had nothing to do with any type of malicious attack, but consequences were disastrous, even though the system was eventually reanimated.
In a case where the attackers take over a hypervisor via whatever means, they would have the entire park of VMs under their control – with all the data stored therein, all incoming and outgoing traffic, etc. It’s a perfect position for cyber-espionage and something that no company would want.
Tips