IPv6 introduces a lot of new features and consequently, a lot of new
capabilities. Obviously, the most significant of them is the huge address space
that it offers. However, this is not the only one. IPv6 also introduces the use
of the IPv6 Extension Headers. The IPv6 header has been considerably simplified
in comparison with IPv4 one. On the other hand, the IPv6 Extension Headers, not
only do the “job” of most of the fields which were removed from the main header,
but, additionally, they add many more. However, any new “technology” creates new
attack opportunities and a “new” protocol, such as IPv6 could not be an
exception, especially since its design and implementation is more complicated
than it’s predecessor.
Almost every higher class DSLR on the market today features multiple and complex
access technologies. To name a few, canons new flagship features IP connectivity
wired via 802.3 as well as wireless via 802.11. All the big vendors are pushing
these features to the market and advertise them with real time image transfer to
the cloud. We have taken a look at the layer 2 and 3 implementations in the
CamOS and the services running upon those, so here is what we found
while examine the EOS 1D X:
Our new
workshop about mobile application testing,
held for the 1st time at the Troopers conference 2013, is coming closer. So I
would like to take the opportunity and post an appetizer for those who are still
undetermined if they should attend the workshop ;-).
While the topic of mobile application testing is a wide field that may contain
reverse engineering, secure storage analysis, vulnerability research, network
traffic analysis and so forth, in the end of the day you have to answer one
question: Can I trust this application and run it on my enterprise devices? So
first you have to define some criteria, which kind of behavior and
characteristics of an application you regard as trustworthy (or not). Let us
peek at malware … besides harming your devices and data, malware is typically:
Here’s a number of updates as for upcoming
TROOPERS13.
The preliminary agenda for this year’s TelcoSecDay can be found
here.
Here‘s
the (again: preliminary) agenda of the IPv6 Security Summit.
Last, but not least we’ve included another four talks in the main conference:
======
Sergey Bratus & Travis Goodspeed: You wouldn’t share a syringe. Would you share
a USB port?
Synopsis: Previous work has shown that a USB port left unattended may be subject
to pwnage via insertion of a device that types into your command shell (e.g.
here).
Impressive attack payloads have been delivered over USB to
jailbreak PS3
and a
“smart TV“.
Not surprisingly, USB stacks started incorporating defenses such as device
registration, USB firewalls, and other protective kits. But do these protective
measures go far enough to let you safely plug in a strange thumb drive into your
laptop’s USB port?
It has been a year since fragmentation attacks in IPv6 were last examined
publicly (in
Black Hat Europe 2012).
Issues well known from the IPv4 era appeared again in IPv6. Surprisingly enough,
some of the most popular Operating Systems (OS), included ones considered
“secure”, were proven to be vulnerable to such attacks, although fragmentation
overlapping is strictly forbidden in IPv6 since 2009 (RFC5722). Some other OS,
although in a better shape, still appeared to have some issues in specific
cases.
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: