The virtualization security (VirtSec) FUD meter is in overdrive this week...
Part I:
So, I was at a conference a couple of weeks ago. I sat in on a lot of talks.
Some of them had demos. What amazed me about these demos is that in
many cases, in order for the attacks to work, it was disclosed that the
attack target was configured by a monkey with all defaults enabled and no
security controls in place. "...of course, if you checked this one box, the
exploit doesn't work..." *gulp*
Part II:
We've observed a lot of interesting PoC attack demonstrations such as those at shows being picked
up by the press and covered in blogs and such. Many of these stories simply ham it up for the
sensational title. Some of the artistic license and innacuracies are just plain recockulous.
That's right. There's ridiculous, then there's recockulous.
Example:
Here's a by-line from an article which details the PoC attack/code that Jon Oberheide used to show
how, if you don't follow VMware's (and the CIS benchmark) recommendations for securing your
VMotion network, you might be susceptible to interception of traffic and bad things since -- as
VMware clearly states -- VMotion traffic (and machine state) is sent in the clear.
This was demonstrated at BlackHat DC and here's how the article portrayed it:
Jon Oberheide, a researcher and PhD candidate at the University of Michigan, is releasing a proof-of-concept tool called Xensploit that lets an attacker take over the VM’s hypervisor and applications, and grab sensitive data from the live VMs.
Really? Take over the hypervisor, eh? Hmmmm. That sounds super-serious! Oh, the humanity!
However, here's how the VMTN blog rationally describes the situation in a measured response that does it better than I could:
Recently a researcher published a proof-of-concept called Xensploit which allows an attacker to view or manipulate a VM undergoing live migration (i.e. VMware’s VMotion) from one server to another. This was shown to work with both VMware’s and Xen’s version of live migration. Although impressive, this work by no means represents any new security risk in the datacenter. It should be emphasized this proof-of-concept does NOT “take over the hypervisor” nor present unencrypted traffic as a vulnerability needing patching, as some news reports incorrectly assert. Rather, it a reminder of how an already-compromised network, if left unchecked, could be used to stage additional severe attacks in any environment, virtual or physical. ...
Encryption of all data-in-transit is certainly one well-understood mitigation for man-in-the-middle attacks. But the fact that plenty of data flows unencrypted within the enterprise – indeed perhaps the majority of data – suggests that there are other adequate mitigations. Unencrypted VMotion traffic is not a flaw, but allowing VMotion to occur on a compromised network can be. So this is a good time to re-emphasize hardening best practices for VMware Infrastructure and what benefit they serve in this scenario.
I'm going to give you one guess as to why this traffic is unencrypted...see if you can guess right in the comments.
Now, I will concede that this sort of thing represents a new risk in the datacenter if you happen to not pay attention to what you're doing, but I think Jon's PoC is a great example of substantiating why you should follow both common sense, security hardening recommendations and NOT BELIEVE EVERYTHING YOU READ.
If you don't stand for something, you'll fall for anything.
/Hoff