We’re very happy to announce the third round of Troopers 2013 talks today (first
round
here,
second
here).
So much quality stuff… it seems to get (ever) better every year ;-).
Here we go:
==================
Michael Ossmann & Dominic Spill: Introducing Daisho – monitoring multiple
communication technologies at the physical layer.
Synopsis: Most communications media can be monitored and debugged at various
levels of the stack, but we believe that it is most important to examine them at
the physical layer. From there, the security of every level can be investigated
and tested. The task of monitoring physical layer communications has become
increasingly difficult as we try to squeeze more and more bandwidth out of our
links. A passive tapping circuit can be used to monitor a 100BASE-TX
connections, but no such circuit exists for 1000BASE-T networks.
We’re very happy to announce the second round of Troopers 2013 talks today
(first round
here).
Some
(well, actually most ;-)) of these talks haven’t been presented before, at any
other occasion, so this is exciting fresh material which was/is prepared
especially for Troopers.
Here we go:
==================
Andreas Wiegenstein & Xu Jia: Ghost in the Shell.FIRST TIME MATERIAL
Synopsis: Security conferences in the past years have made it clear, that
common security vulnerabilities such as SQL Injection, XSS, CSRF, HTTP verb
tampering and many others also exist in SAP software. This talk covers several
vulnerabilities that are unique to SAP systems and shows how these can be used
in order to bypass crucial security mechanisms and at the same time operate
completely below the (forensic) Radar. We uncovered undocumented mechanisms in
the SAP kernel, that allow launching attacks that cannot be traced back to the
attacker by forensic means. These mechanisms allow to *actively* inject
commands at any time into the running backend-session of an arbitrary logged on
user, chosen by the attacker. We named this attack mechanism “Ghost in the
Shell”. We will also demo how to use this attack vector to distribute malware to
the attacked user’s client machine despite mechanisms in the SAP standard that
are designed to prevent this.
The root cause of the vulnerability is Rails handling of formatted
parameters. In addition to standard GET and POST parameter formats, Rails can
handle multiple different data encodings inside the body of POST requests. By
default JSON and XML are supported. While support for JSON is widely used in
production, the XML functionality does not seem to be known by many Rails
developers.
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.
The CTL is basically a binary TLV file with 1 byte type, followed by 2 bytes
length and finally the data. But as this is far to easy, some special fields
omit the length field and just place the data after the type (I guess those are
fields with a fixed length). Here is an example CTL file:
Some of you may have heard the topic before, as we have spoken about on this
years BlackHat Europe, TROOPERS12 and HES12,
so this is nothing completely new, but as we’re done with responsible disclosure
(finally (-; ) and all the stuff should be fixed, we’re going to publish the
code that brought us there. I will split the topic into two blog posts, this one
will wrap up the setup, used components and protocols, the next one [tbd. till
EOY, hopefully] will get into detail on the tools and techniques we used to
break the enterprise grade security.
We’re delighted to provide the first announcement of talks of next year’s
Troopers edition. Looks like it’s going to be a great event again 😉
Here we go:
==================
Peter Kieseberg: Malicious pixels – QR-codes as attack vectors.
**Synopsis: **QR-Codes, a version of two-dimensional barcodes that are able to
store quite large amounts of information, started gaining huge popularity
throughout the last few years, including all sorts of new applications for them.
Originating from the area of logistics, they found their ways into marketing and
since the rise of modern smartphones with their ability to scan them in the
street; they can be found virtually everywhere, often linking to sites on the
internet. Currently even standards for paying using QR-codes were proposed and
standardized. In this talk we will highlight possible attack vectors arising
from the use of QR-Codes. Furthermore we will outline an algorithm for
calculating near-collisions in order to launch phishing attacks and we will
demonstrate the practical utilization of this technique.
2 AFFECTED PRODUCTS The following Products have been tested as vulnerable so far: Cisco Unified Meetingplace with the following modules: • MeetingPlace Agent 7.1.1.9 • MeetingPlace Audio Service 7.1.1.8 • MeetingPlace Gateway SIM 7.1.1.2 • MeetingPlace Replication Service 7.1.1.9 • MeetingPlace Master Service 7.1.1.8 • MeetingPlace Extension 7.1.1.8 • MeetingPlace Authentication Filter 7.1.1.8
3 DETAILS The following parameters are affected: http://$IP/mpweb/scripts/mpx.dll [POST Parameter wcRecurMtgID]
4 VULNERABILITY SCORING The severity rating based on CVSS Version 2: Base Vector: (AV:N / AC:L / Au:S / C:P / I:P / A:P) CVSS Version 2 Score: 6.5 Severity: Low
Almost all of our presentations and write-ups on the VMDK File Inclusion
Vulnerability contained a slide stating something like
“we’re rather sure that DoS is possible as well ;-)”
including the following screenshot of the ESX purple screen of death:
So it seems like we still owe you that one — sorry for the delay! However the
actual attack to trigger this purple screen was rather simple: Just include
multiple VMDK raw files that cannot be aligned with 512 Byte blocks — e.g.
several files of 512 * X + [0 < Y < 512] Bytes. Writing to a virtual hard
drive composed of such single files for a short amount of time (typically one to
three minutes, this is what we observed in our lab) triggered the purple screen
on both ESXi4 and ESXi5 — at least for a patch level earlier than
Releasebuild-515841/March 2012: it seems like this vulnerability was patched in
Patch
ESXi500-201203201-UG.
