Q&A: Can VENOM Take a Bite Out of Your Data Center?
Security researchers have uncovered a potentially major vulnerability, which they named VENOM, that affects virtual machines. IT departments, particularly those housed in environments that use a lot of virtualization, are scrambling to understand the ramifications of this new threat.
We asked Trustwave Threat Intelligence Manager Karl Sigler to explain how the bug operates, what risk it poses to organizations and whether it rivals a certain high-profile vulnerability from 2014.
Q: We're adding a new "celebrity" vulnerability to the list with the discovery of the frightful-sounding VENOM. What's it all about?
A: VENOM (Virtualized Environment Neglected Operations Manipulation) is a new vulnerability that affects virtual environments that allow you to run multiple virtual systems on a single "bare metal" machine. The vulnerability can be exploited to allow the attacker to "break out" of their virtual machine and access the "bare metal" machine, a.k.a. the underlying hypervisor or any other of the virtual machines running on the system. This specific vulnerability is in QEMU's (an open-source hypervisor) code for virtual floppy drives. This code is reused in many different open-source virtualization platforms like Xen and KVM. Microsoft Hyper-V and VMWare virtualization solutions, however, are not vulnerable.
Q: What makes this vulnerability unique?
A: These types of vulnerabilities are known as "virtual machine (VM) escape" vulnerabilities, and we've seen similar bugs in the past. VENOM, however, affects a wider list of virtualization platforms and can lead to arbitrary code execution even with default configurations. As far as VM escape vulnerabilities go, this is probably as bad as we've seen.
Q: What could be the consequences?
A: It's dependent on what data is available on the virtual machines to which the attacker gains unauthorized access. Any attacker would potentially have full system access on every virtual machine on the same hypervisor. The more valuable the systems, the more critical the breach. For instance, if a virtual machine was hosting an e-commerce website, an attacker could steal credit card numbers from the backend database, manipulate prices or infect visitors with malware. But if the virtual system were simply a forgotten test box never used in production, they wouldn't get as much of a payday.
Q: The vulnerability has been compared to Heartbleed. Is it a worthy comparison?
A: No, and I say that for a couple of reasons. While Heartbleed can be exploited remotely with anonymous access, VENOM can only be exploited if you have access to an existing virtual machine. In this sense, it works very much like a privilege escalation attack. This limits the severity a bit. Also while VENOM does affect the popular virtualization platforms of XEN, KVM, QEMU and VirtualBox, the absence of VMWare and Microsoft Hyper-V as affected technology eases the blow for a lot of virtualization deployments.
Q: How might attackers leverage this vulnerability to cause harm and who is most at risk?
A: I would see this attack typically used to target hosting companies that use virtual environments like KVM. An attacker would purchase a cheap virtual private server instance, and then use VENOM to breach the hosting machine.
Q: Has anyone been attacked "in the wild" through a VENOM exploit?
A: No, there have been no attacks seen in the wild and there is currently no "proof of concept" or exploit. Hopefully, this will give administrators some breathing space to apply a patch.
Q: So that means businesses can protect themselves from VENOM?
A: There is a patch available for most of the affected platforms. Admins should check with their specific virtualization vendor. Businesses should also be applying some basic best practices. Since virtual machines are often used for testing purposes - and then forgotten about once that testing is complete - the idea of virtual server "sprawl" introduces unnecessary risk to the network. Conducting regular vulnerability inventory scans can often flag virtual systems that you didn't even know had been deployed.
It's also very important to remember that virtual environments typically are heterogeneous. You must keep a proper inventory of virtual machines and segment them from each other based on value and risk. This would help mitigate any damage that might occur if those systems are breached.
