As you probably know we perform research on a regular base at ERNW.
We – Olga and Rafael – started with a research project about Bluetooth. Our
first goal was to gain some knowledge about the tools used by most Linux systems
to communicate with Bluetooth hardware, such as BlueZ. A good help for that was
the amazing Bluetooth hacking workshop we had before (check
the link in
our blog!)
To get a better understanding of the tools you need some Bluetooth hardware to
interact with.
The hardware we used for our research so far are the very cool TexasInstruments
SimpleLink™ Bluetooth low energy/Multi-standard SensorTag (CC2650STK) and a
Fitness Wristband found at home.
T-mobile pioneered with the native seamless support for WiFi calling technology
embedded within the smartphones. This integrated WiFi calling feature is adopted
by most major providers as well as many smartphones today. T-mobile introduced
VoWiFi in Germany in May 2016. You can make voice calls that allows to switch
between LTE and WiFi networks seamlessly. This post is going to be about
security analysis of Voice over WiFi (VoWiFi), another name for WiFi calling,
from the user end. Before we get started, let me warn you in advance. If you are
not familiar with telecommunication network protocols, then you might get lost
in the heavy usage of acronyms and abbreviations. I am sorry about that. But
trust me, after a while, you get used to it 🙂 .
It’s almost exactly seven years since Enno published the very first blog post on
Insinuator.net. Meanwhile, quite a few things changed. It’s not only the ERNW
Universe which grew significantly, but also Insinuator’s place within this
universe was slightly adjusted. What started as an almost independent
IT-Security blog became more and more the major publication medium of ERNW.
Therefore, we thought it would be a good time to reflect these changes. Today we
release the 2.0 version of Insinuator.net. 2.0 introduces a new look & feel as
well as major redesign from a technical point of view while also reflecting
Insinuator’s place between the four major players in the ERNW universe:
Today it is my pleasure to shortly introduce ERNW’s Capture the Flag team, the
Kernel Space Invaders. As a long-time CTF enthusiast, I’m really amazed how many
of us make the time to tackle IT security challenges also on the weekends or
evenings. Even if we cannot participate in all CTFs out there (which would be
challenging anyways given the
large number of CTF events happening nowadays), we
started to compile a repository of some
of our write-ups — I hope some of you will enjoy!
Some years ago I discussed the meaning of the term “control” in
this post,
but at the time I was mainly referring to the noun “control”. Given I’ll
extensively use the term “control” as a verb in the next parts of “the
DMZseries”
and some upcomingtalks I reflected a bit on its meaning
(as a verb). In the following I’ll lay out the definition/understanding to be
employed at those occasions.
In this post I want to add (yet) another perspective, motivated by a disclosure
procedure which just happened recently.
todb’s article,
R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open
is a well planned public forum vulnerability disclosure. The article itself is
very well done: It gives credit to the researcher who discovered the
vulnerability and it shows a vulnerability disclosure timeline where Rapid7
reached out to Comcast (the vendor). They even go a step further and publish the
link showing the process for discovered vulnerabilities in a Rapid7 product as
well as how Rapid7 handles disclosing those vulnerabilities they find in
external products. For their internal disclosure process, they make sure to
release a patch before “publicly announcing the vulnerability in the release
notes of the update”(rapid7 disclosure).
Given there’s quite some speculation and, as we think, misinformation going
around we think it’s helpful to add/clarify the following information:
we fully comply with the injunction and we have no intentions to violate it.
we do not plan to publish any technical information besides the report (agreed
upon with FireEye themselves) and the slides (based on the former) anyway. No
3rd parties except for the ones involved (FireEye, lawyers) have received any
additional technical information from our side, let alone an earlier version
of the report.
the injunction covers accompanying details mostly within the architecture
space, but not the core vulnerabilities themselves. Those are not part of the
injunction.
we stand by the timeline as provided below. In particular, the following two
points:
– FireEye received a draft version of the report which had the objectionable
material (as identified by the cease and desist letter) fully removed on
August 11th.
– according to the cease and desist letter FireEye’s lawyer sent us, they were
informed – from our side – about the planned talk at 44CON on Jul 23rd.
there’s an injunction, but not a lawsuit. I used the term “sue” after
consulting Merriam-Webster
which states: “sue: to seek justice or right from (a person) by legal
process”, but this might have been misinterpreted by some readers. As stated,
there’s a pending injunction, but not a lawsuit.
Please note that we won’t share legal documents with 3rd parties or publish them
as we consider this inappropriate.
Please note further that, during the whole process, our goal was to perform a
responsible disclosure procedure with its inherent objectives (namely
vulnerability remediation by vendor and education of various stakeholders
involved, see also
here
or
here).
We consider this disclosure process as concluded. We don’t see a need to add
technical details from our side as we feel that the objectives of responsible
disclosure are met (not least as patches are released since quite some time
and both
vendor & finder
have released reports).
Some of you might use WebEx in their daily life. And some of you might use Linux
(as I and many of us do). However, this combination often results in issues with
your PC’s sound or microphone use in a WebEx session.
The problem here is that WebEx won’t run as intended with Firefox and JRE x64.
But the solution is quite easy! Use the x86-versions of each.
In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want
to delve into an abstract & general discussion of vulnerability disclosure (for
those
interested here’s some discussion in
the context of Google’s Project Zero,
this is the well-known CERT/CC approach,
this a paper from WEIS 2006
laying out some variants, and
finally some statement by Bruce Schneier back in 2007). Instead
I will lay out which approach we followed in the past (and why we did so) and
which developments make us consider it necessary to re-think our way of
handling. The post is not meant to provide definitive answers; it was also
written not least to provide clarity for ourselves (“write down a problem in
order to better penetrate it”) and, maybe, to serve as a starting point for a
discussion which will help the community (and us) to find a position on some of
the inherent challenges.
We’re sometimes approached with the question “Which IPv6 mailing lists do you
guys read/subscribe to?” – here’s a quick overview of the main ones guys like
Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at,
to discuss IPv6 (network|security) related stuff with other practitioners and
to learn from them: