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.
