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.
If you want to extract some data from a database you first need to gather
knowledge about the internal structure of the database.
One of the first steps (after determining the database type) is enumerating the
available tables and the corresponding columns. Most database systems have a
meta database called information_schema. By querying this database it is
possible to get information about the internal structure of the installed
databases. For example you could get the tables and their corresponding columns
in MS SQL and MySQL by injecting
“SELECT table_name, column_name FROM information_schema.columns“. Oracle
databases have their own meta tables, so you have to handle them differently.
For getting the same output in Oracle, you have to query the all_tab_columns
table (or user_tab_columns if you only want to search in the currently selected
database). If the found vulnerability only allows to receive a single column (or
if it is too complicated to identify two columns in the server response) you
could concatenate the columns to one single string, e.g. in Oracle:
“SELECT table_name||':'||column_name FROM all_tab_columns“.
As announced at last week’s
#HITB2012AMS, I’ll describe
the fuzzing steps which were performed during our initial research. The very
first step was the definition of the interfaces we wanted to test. We decided to
go with the plain text VMDK file, as this is the main virtual disk description
file and in most deployment scenarios user controlled, and the data part of a
special kind of VMDK files, the Host Sparse Extends.
There are some database specifics, every pentester should be aware of, when
testing for and exploiting SQLi vulnerabilities. Besides the different string
concatenation variants already covered above, there are some other specifics
that have to be considered and might turn out useful in some circumstances. For
example with Oracle Databases, every SELECT statement needs a following FROM
statement even if the desired data is not stored within a database. So when
trying to extract e.g. the DB username using a UNION SELECT statement, the DUAL
table may be utilized, which should always be available. Another point, if
dealing with MySQL, is the possibility to simplify the classic payload
A
quick update on the workshop we’ve just finished at
Hack in the Box 2012 Amsterdam:
Due
to popular demand we decided to bring the slides online without wasting any more
time. The official website of the conference is currently experiencing some
problems due to high interest in all the stuff what was released in the last two
days. Great conference!
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.
Hi @all,
today im releasing a new version of our famous fuzzing framework, dizzy. The
version counts 0.6 by now and youll get some brand new features!
see the CHANGELOG:
v0.6:
– ssl support
– server side fuzzing mode
– command output
– new dizz funktions: lambda_length, csum, lambda_csum, lambda2_csum
– recursive mutation mode
– new dizz objects: fill
– new interaction objects: null_dizz
– reconnect option
– additional fuzzing values
As
in 2011
we really liked the conference; there was a number of interesting talks and we
met quite some fellows from the IPv6 security space. Btw: we plan to organize a
dedicated IPv6 security summit in late 2012 (probably on 6th and 7th of
November) in Heidelberg, similar to the
Telco Sec Day
at Troopers. We’ll annouce details as for this one in some weeks.
As I mentioned the Telco Sec Day in the last post… for those who missed Flo’s
announcement: in the interim all slides of the Telco Sec Day are available
online here.
Obviously, given I initiated the event, I’m biased 😉 but to me it provided
great insight from both the talks and the networking with other guys from the
telco security field, and it did actually what it was meant for: fostering the
exchange between different players in that space, for the sake of sustainably
improving its’ overall security posture.
SQL injection attacks have been well known for a long time and many people think
that developers should have fixed these issues years ago, but doing web
application pentests almost all the time, we have a slightly different view.
Many SQL injection problems potentially remain undetecteddue to a lack of
proper test methodology, so we would like to share our approach and experience
and help others in identifying these issues.