In today’s Whiteboard Wednesday, Justin Pagano, Security Engineer at Rapid7, will discuss the VENOM vulnerability. VENOM is a vulnerability that takes place within the virtual floppy drive code of a virtual machine. If properly exploited, attackers can laterally move from the affected VM and have access to the host, putting your critical assets in jeopardy
Hi. My name's Justin Pagano. I'm a security engineer here at Rapid7. For today's Whiteboard Wednesday we're going to go over the recently disclosed VENOM vulnerability. VENOM stands for virtualized environment neglected operations manipulation. This vulnerability is present in the virtual floppy disk controller or FDC code that's present in a hypervisor package called QEMU. This FDC code is also used in other hypervisor packages such as Xen and KVM.Show more Show less
If an attacker were to exploit this vulnerability, they would be sending malicious parameters to the FDC that's running on a virtual machine. That FDC allows the virtual machine to communicate with the underlying host and act like a floppy disk drive when really there isn't a physical one present. The attacker can cause a buffer overflow within the FDC, break out of the VM, and potentially access other VMs within that hypervisor. They could also have access to the underlying bare metal systems hardware and use that to see other systems on the hypervisor's network. There's a pretty big risk here of an attacker lateraling out of a VM to other virtual machines that are supposed to be sealed off from the one they're on and also to other stand alone systems and other hypervisors that might be on that same network. We're talking about the potential for an attacker to get access to your company's intellectual property or to sensitive information such as PII.
The ways you can defend against this start out with patching. That's something we always talk about when we're managing vulnerabilities. Patches are out for operating systems like Red Hat Enterprise Linux and Debian. More patches are probably on the way. You might have some appliances on your network that could be running one of these hypervisor packages which will need a patch from the vendor that creates the appliance.
You could also try some mitigating techniques if you have more control over operating systems that are running these hypervisors. For example, you could try running SELinux which will help control what kind of access these different VMs have to the resources on the underlying host operating system, so if an attacker were to exploit VENOM on a VM, SELinux would limit the other resources that the attacker could get to outside of the VM. You could also try implementing access controls on your VMs so any users that are logging into them don't have administrative rights or root privileges. That will greatly reduce the likelihood of an attack like this from occurring. Finally, if you don't have control over your virtualized resources because you're using an infrastructure as a service provider, you'll want to contact that provider or vendor to see whether or not they're vulnerable, and if they are when a patch would be coming out.
That's it for today. Thanks for joining, and we'll see you next week