First of all, I hope you all had a good start to 2014. Having some time off “between the years” (which is a German saying for the time between Christmas and NYE), I caught up on several virtualization security topics.
While virtualization is widely accepted as a sufficiently secure technology in many areas of IT operations (also for sensitive applications or exposed systems, like DMZs) by 2014, there are several recent vulnerabilities and incidents that are worth mentioning.
with the rise of low-cost 3D-printers in the homes of thousands [1] of enthusiastic tinkerers the word spreads about these magical machines which can produce any mechanical, artsy, useful or useless parts you might come up with. Standing in living rooms worldwide, they don’t seem like a big threat [2] to anybody. But what happens if you connect them to the Internet?
In the course of a current virtualization research project, I was reviewing a lot of documentation on hypervisor security. While “hypervisor security” is a very wide field, hypervisor breakouts are usually one of the most (intensely) discussed topics. I don’t want to go down the road of rating the risk of hypervisor breakouts and giving appropriate recommendations (even though we do this on a regular base which, surprisingly often, leads to almost religious debates. I know I say this way too often:I’ll cover this topic in a future post ;)), but share a few observations of analyzing well-known examples of vulnerabilities that led to guest-to-host-escape scenarios. The following table provides an overview of the vulnerabilities in question:
The gritsforbreakfast blog post making the rounds on the Liberation Tech mailing list about security of Apple’s iMessaging service is gaining quite some attention. The post refers to a CNET article on how the iMessage service “stymied attempts by federal drug enforcement agents to eavesdrop” conversations due its end-to-end encryption and commends Apple for protecting the user’s privacy while pointing out that Gmail and Facebook Messaging don’t. However, I disagree on some points of the blog post and therefore want to discuss them here.
Last week Rapid7 posted an interesting analysis of the Amazon S3 storage system: Apparently roughly one out of six S3 buckets (a bucket is, simply said, a kind of folder) is accessible without any authentication mechanism. Accessing those files, the Rapid7 guys were able to download a wide range of data, also comprising confidential information such as source code or employee information, comparable to past research for other platforms (see also this presentation I gave on some of the biggest Cloud #Fails)
As you may already be familiar with some of our previouswork which was mainly focused on isolation issues of hypervisors, we also want to present you an issue concerning availability in Cloud environments. This issue was already covered in some of our presentations, but will be explained in greater detail in this blog post.
In the course of one of our security assessments of a public IaaS Cloud environment, we experienced the following network setting:
Yesterday I was giving two presentations about Cloud security at the BASTA! Spring 2013 Security Day. While my presentations covered Microsoft Azure security considerations (which also included a part of the Cloud security approach covered in our workshops; slides available here) and some major Cloud incidents (suitable to transport different messages about Cloud security in general ;); slides available here), I also saw Dominick’s very interesting presentation about security aspects and changes in Windows 8. Inspired by that, we hope to be able to publish another blogpost on those aspects with regard to enterprise environments soon — most likely we won’t find any time for it before TROOPERS 😉
at first a happy new year to all our readers!
And, of course, to everybody else, too ;-). May 2013 bring good things for you all, in particular (but not only) in the infosec space.
At the recent ATSAC 2012 conference a guy from the CERT Insider Threat Center gave a talk on the exact topic. Given that the ENISA Cloud Computing Risk Assessment lists “Cloud Provider Malicious Insider” as one of the top eight risks (out of overall 35 risks evaluated) and we just had some discussion about this in a customer environment, this might be of interest for some readers.
As we are receiving a lot of questions about our VMDK has left the building post, we’re compiling this FAQ post — which will be updated as our research goes on.
** **
How does the attack essentially work?
By bringing a specially crafted VMDK file into a VMware ESXi based virtualization environment. The specific attack path is described here.
* *
What is a VMDK file?
A combination of two different types of VMDK files, the plain-text descriptor file containing meta data and the actual binary disk file, describes a VMware virtual hard disk. A detailed description can be found here.
Update #1: Slides are available for download here.
In the course of our ongoing cloud security research, we’re continuously thinking about potential attack vectors against public cloud infrastructures. Approaching this enumeration from an external customer’s (speak: attacker’s 😉 ) perspective, there are the following possibilities to communicate with and thus send malicious input to typical cloud infrastructures:
Management interfaces
Guest/hypervisor interaction
Network communication
File uploads
As there are already several successful exploits against management interfaces (e.g. here and here) and guest/hypervisor interaction (see for example this one; yes, this is the funny one with that ridiculous recommendation “Do not allow untrusted users access to your virtual machines.” ;-)), we’re focusing on the upload of files to cloud infrastructures in this post. According to our experience with major Infrastructure-as-a-Service (IaaS) cloud providers, the most relevant file upload possibility is the deployment of already existing virtual machines to the provided cloud infrastructure. However, since a quick additional research shows that most of those allow the upload of VMware-based virtual machines and, to the best of our knowledge, the VMware virtualization file format was not analyzed as for potential vulnerabilities yet, we want to provide an analysis of the relevant file types and present resulting attack vectors.