Just a quick update here: Ivan (who gave the magnificent
Virtual Firewalls
talk at Troopers recently) blogged about this and some
guy added some feedback from an environment with Cisco FEX and “one of the
server guys start[ing] a Citrix Netscaler” ;-). See the second comment to his
post.
This shows, once more, that the dependencies of various technologies (and what
they are used for) must be well understood in cloud/virtualized environments.
Complexity … but who do we tell. Y’ all know that, right?
In our last series of posts regarding the VMDK file inclusion attack, we focused
on read access
and
prerequisites
for the attack, but avoided stating too much about potential write access. But
as we promised to cover write access in the course of our future research, the
following post will describe our latest research results.
First of all, the same
prerequisites
(which will be refined a little bit more later on) as for read access must be
fulfilled and the same
steps have to
be performed in order to carry out the attack successfully. If that is the case,
there are several POIs (Partitions Of Interest) on a ESXi hypervisor that are
interesting to include:
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.
Two days ago I gave the keynote at an industry event, reflecting on the changing
role of traditional security controls in the age of virtualization and the
cloud. As this was an updated version of the stuff distributed in the conference
proceedings, some people have asked for it. Voilà,
here we go.
Just wanted to let you know that we sent out
ERNW Newsletter 32
end of last week. As we
promised
it includes the results of research regarding the question “Is browser
virtualization a valid security control in order to mitigate browser based
security risks?”.
Simon did a great job with writing the latest newsletter. It’s a 30-page
document which should help you to have a basis for well-informed decisions when
it comes to the deployment of an application virtualization technology.
One of the biggest pains in the ass of most ISOs – and subsequently subject of
fierce debates between business and infosec – is the topic of “Browser
Security”, i.e. essentially the question “How to protect the organization from
malicious code brought into the environment by users surfing the Internet?”.
Commonly the chain of events (of a typical malware infection act) can be broken
down to the following steps:
1.) Some code – no matter if binary or script code – gets transferred (mostly:
downloaded) to some system “from the Internet”, that means “over the network”.
Today was an interesting day, for a number of reasons. Amongst those it stuck
out that we were approached by two very large environments (both > 50K
employees) to provide security review/advise, as they want to “virtualize their
DMZs, by means of VMware ESX”.
[yes, more correctly I could/should have written: “virtualize some of their DMZ
segments”. but this essentially means: “mostly all of their DMZs” in 6-12
months. and “their DMZ backend systems together with some internal servers” in
12-24 months. and “all of this” in 24-36 months. so it’s the same discussion
anyway, just on a shifted timescale ;-)]