Insights from Black Hat and DEFCON 2015: Agencies beware of hypervisor exploitation in public clouds
(See update on 10/20/2015 below, no longer a theory!)
Multiple presentations at both Black Hat 2015 and DEFCON23 examined hypervisor vulnerabilities, as well as the firmware and hardware vulnerabilities that can give attackers access to either the layer-2 ring (hypervisor ring) or other VMs’ memory and CPU stream. All together, the lesson for federal agencies is this: Beware of vulnerabilities that have nothing to do with the security infrastructure or compliance that cloud providers work so hard to supply.
The most explosive problem was demonstrated in two separate presentations. The first came from a live demonstration by the Intel Security Labs, whose team used hardware vulnerabilities to pull private SSH keys and full MS Word documents stored in memory of completely separate and unconnected VMs. This required privileged access to the hardware that a standard cloud user would not have. Although they did not demonstrate gaining that access, several other presentations at Black Hat and DEFCON showed how that could be achieved.
The most powerful privilege escalation vulnerability can only be resolved by replacing all Intel-based CPU cores in any environment—virtual, cloud, or otherwise—with the very latest Intel chipset, due to a legacy APIC chip that was only most recently removed. In short, any Intel-based system older than one year has no remedy for elevating privileges, which then could give a legitimate cloud-purchased session access to the files and SSH keys of any neighboring VM.
The second presentation on VM data exfiltration was presented by Etienne Martineau, who is a Cisco employee, but was not representing Cisco. Etienne explained how VMs that are co-located on CPU cores create a vulnerability for covert channels that allows data exfiltration and full shell code execution. This can be accomplished WITHOUT privilege escalation.
Let that sink in. In the first case, privilege escalation is trivially accomplished on most systems and data exfiltration is easily accomplished once privilege escalation is achieved. In the second case, VMs using shared resources create a vulnerability that allows for data exfiltration and shell access between unauthorized VMs. All this is achieved with no privilege escalation and very little indicators of compromise to alert IT teams of a problem.
Another type of attack was demonstrated by Sophia D’Antoine, a security researcher at Trail of Bits. D’Antoine show how Intel out-of-order execution vulnerabilities could allow a VM user to inject commands into the execution steam of a completely separate VM. In the live demonstration, she only showed the ability to blue-screen the neighboring VM by injecting random commands. However, she pointed out that by dedicating more time to the correct commands injected, an attacker could execute code without crashing the neighboring VM.
Even if they only had the ability to crash neighboring VMs, bad actors could legitimately acquire access to public cloud systems and then maliciously crash important and possibly critical applications being hosted in a shared public cloud. In a private or internally hosted cloud, the attacker would have to first breach the perimeter and, more than likely, not need to use this method of disruption.
Finally, the last vulnerability was presented by Clarkson University’s Ronny L. Bull and Jeanna Matthews. They explained how layer-2 virtual networking could potentially be used to:
- Capture all network traffic
- Redirect traffic
- Perform Man-in-the-Middle attacks
- Launch Denial-of-Service attacks
- Gain unauthorized access to restricted sub-networks
- Undermine performance
They tested all four of the most popular virtualization platforms: Citrix, VMware, Open v-Switch, and Hyper-V. They also provided mitigation and suggestions for two specific attack types that could be used to achieve these results, DHCP attacks and MAC address attacks.
Not all of these vulnerabilities can be mitigated. However, the presenters each gave suggestions and guidance for the best way to approach these issues. SwishData can help arm agency teams with the knowledge to deploy their own resources to mitigate these problems or, if agencies do not have sufficient resources, we can either provide services or recommend other security providers to assist.
It was only a theory that a public cloud could be hacked using hyper-visor vulnerabilities until last week. At Amazon’s re:Invent, researchers were able to demonstrate through a now closed vulnerability that it could be done INSIDE OF A PUBLIC CLOUD.
Yes, this vulnerability has been stopped, but it will keep happening. New vulnerabilities will be found and closed, but it just proves that Federal Government agencies should not be putting data on public clouds that co-locate their data with consumers and non-government customers. There are many public clouds that are only available to government customers. As long as the customers are vetted to be government, it is one more layer of protection.