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).
This year’s Black Hat US saw a number of quite interesting talks in the context
of Windows or Active Directory Security. For those of you too lazy to search for
themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to
Vegas due to heavy project load) I’ve compiled a little list of those.
Paul Stone &
Alex Chapman: WSUSPect – Compromising the Windows
Enterprise via Windows Update
Slides here.
Whitepaper
here.
(Attention: on the BH website there’s an older this. the above link leads to the
latest one).
Although a bit on short notice it was a good meeting with interesting
discussions. I contributed with shortened versions of two talks we had delivered
in the past:
the “MLD Considered Harmful” talk that Antonios,
Jayson and I had presented at the
Troopers IPv6 Security Summit 2015.
The mentioned Internet-Draft on MLD security which
Eric Vyncke, Antonios and myself are
working on can be
found here.
We’re happy to receive any feedback on that one.
Special thanks go to
Jan Zorz
and to CZ.NIC for hosting us and providing refreshments.
Much appreciated, guys!
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.
When we wrote our initial blogpost regarding the
evasion of Cisco ACLs by (Ab)Using IPv6,
where we described
(known to Cisco)
cases of Access Control Lists (ACL) circumvention, we also suggested some
mitigation techniques including the blocking of some (if not all) IPv6 Extension
Headers.
Almost a month later, we got
a comment
from Matej Gregr that, even if the ACLs of certain Cisco Switches are
configured to block IPv6 Extension headers like Hop-by-Hop or Destination
Options headers, this does not actually happen/work as expected. Of course this
made us re-visit the lab in the interim ;-).
In the course of a customer project I recently documented some thoughts and
general objectives of IPv6 address planning, expanding on stuff I wrote a while
ago in the
series on “Address Plan Considerations”.
An excerpt of that (newer) document
can be found here.
Due to the context it originates from it’s in German, still I hope it’s useful
for some readers.
If you’re interested in the topic it might be a good idea to listen to
Tom Coffeen‘s talk at the upcoming
IPv6 Business Conference, too.
“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more
from IPv6?”
While I highly value Scott’s IPv6 expertise – not least because I learned a lot
about IPv6 security from
the book on the topic
he wrote together with Eric Vyncke – I
strongly disagree with his statement, mainly with the first part. In this post I
will lay out why I think that IPv6 is actually less secure than IPv4.
IPv6 is often called a “complex protocol”, not least by myself (for example in
my
keynote to the IPv6 Security Summit 2014). In
this post I want to have a quick look at three questions:
– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?
I’d like to start with some clarifications and a definition. First of all: when
I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family”
incl. those helper protocols needed to support (“core”) IPv6 in performing
properly in most networks, like ICMPv6 and MLD.
Then, of course, we have to define the term “complexity”, which is a difficult
task in itself. [MITCHELL2009] gives an overview of several potential
(definition) approaches in a dedicated chapter and the same undertaking is
performed – in quite different ways – by most of the authors of individual
contributions to [PELITI1988].
Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being
part of the group was fun as always and we had quite some interesting
conversations with peers from the IPv6 community.
We could even contribute a bit to some discussions, with two talks. I gave one
titled “Will It Be Routed? – On IPv6 Address Space Allocation & Assignment
Approaches in Very Large Organizations” in the Address Policy Working Group
session on Wednesday. This is the abstract: