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:
Recommendations by the
German Federal Office for Information Security
(BSI – Bundesamt für Sicherheit in der Informationstechnik) are obligatory for
German government agencies, civil services and authorities (like recommendations
of the NIST are relevant to American government agencies and authorities). They
are often used as references and security best practices in other countries as
well. Hence it is hard to understand why the recommendations on how to harden
Windows Server 2008 based systems were published only some weeks ago and
only on a preliminary draft basis (which is, obviously, better than nothing
;-)).
Last week I read about the new networking features of the integrated vSwitch of
Hyper-V 3.0. I was quite surprised that RA Guard will be natively supported and
was curious about implementation and functionality. If you don’t know how RA
Guard works, I recommend reading our previous blog posts
here,
here,
here,
here
and
here,
or have a look at our workshop at
Troopers12.
I downloaded Windows Server 2012 RC to do some practical testing. Since my
girlfriend was working the whole weekend, I had plenty of time to play around
with all that stuff without risking trouble 😉
As every year, we
will be attending Day-Con, a one-day security summit in
Dayton, OH — this year for its VIth edition. Even though the actual conference
comprises “only” one day full with talks and discussions (please find the agenda
here), the overall event
consists of trainings before the conference
and PacketWars battles (including an infamous party)
afterwards. Since we will be leading and attending some of the training
sessions, those might be of particular interest for people who missed our
Troopers workshops — so
you don’t have to wait a whole year but get another chance in October 😉
Some days ago another
advisory
related to a web application firewall (WAF) product was published. This time the
product Airlock by Ergon was affected by a vulnerability
that combines Encoding and NULL Byte attacks to circumvent the pattern based
detection engine. We have described these attacks in detail in our newsletter
“Web Application Firewall Security and The Swiss Army Knife for Web Application Firewalls”
because they belong to a well known category of attacks against WAFs.
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!