Yesterday we (Rafael Schaefer, Enno and me) had the pleasure to deliver together
our talk at BlackHat Europe 2014 named
Evasion of High-End IDPS Devices at the IPv6 Era
(by the way, latest slides can be found
here
and the white paper
here).
In this talk we summarised all the IDPS evasion techniques that we have found so
far. At previous blogposts I had the chance to describe how to evade
Suricata
and
TippingPoint.
In this post I am going to describe some other techniques that can be used to
evade Snort, and its companion commercial version,
Sourcefire. The tool used to evade these IDPS
is – what else
– Chiron.
Some hours ago Iljitsch van Beijnum posted
an email
with the above subject to the RIPE Best Current Operational Practices (BCOP)
mailing list.
Therein he describes the growing issue of (IPv6 prefix) deaggregation
desires/approaches by certain organizations vs. the filtering practices of other
organizations (providers). I touched this problem, from an enterprise’s
perspective, some time ago in the
second part
of my blog post series on
IPv6 address planning.
Given we think that the discussion is heavily needed from several angles, I
had actually submitted a talk on the topic twice (for the RIPE meeting in Warsaw
in May and the upcoming one in London) which was unfortunately rejected at both
occasions.
I’m hence very happy to see that a dialogue about the inherent dilemma might be
started by Iljitsch’s mail. As a contribution to the development of a BCOP
document I will hereby publish
our draft slides
of the talk which was initially planned. Furthermore two fellow IPv6
practitioners (Hi Roland & Nico!) and I plan to release a detailed paper with
research results as for IPv6 prefix distribution at major European IXs in the
near future.
I know I am a bit late with this post, but I was speaking on the
North American IPv6 Summit
in Denver three weeks ago. The focus of my talk was on
Why IPv6 Security is hard – Structural Deficits of IPv6 & Their Implications
(slightly modified/updated from the
Troopers IPv6 Security Summit).
We consider the NA IPv6 Summit as one of the most important IPv6 events at all
and we were happy to contribute to the overall success. The conference was
organized for the 7^(th) time by the
Rocky Mountain IPv6 Task Force and took place in the
Grand Hyatt Denver (37th floor ;-)). Luckily the weather was perfect, and the
view of the landscape from the conference rooms was just amazing. I really
enjoyed the time in Denver, as the organizer sdid all they could to treat the
speaker well J. The talks were of mix of regular research or case-study type
talks and some sponsored talks ranging from deployment experience, security and
statistics to SDN (Yes, I said it ;)) and the Internet of Things (I said it
again ;)). The line-up was nicely put together.
Last week I had the pleasure to give you my impressions regarding my experience
about
hacking for b33r at Ghent,
that is, my participation at BruCON 2014 hacking
conference. As I said among else, the reason that I was there was to present
Chiron, my IPv6 penetration
testing/security assessment framework, which was supported by the
Brucon 5×5
program. The first version of Chiron had been presented at
Troopers 14,
during the
IPv6 Security Summit.
Today we had the opportunity at ERNW to have a full-day discussion about MLD.
The discussion was led by Jayson Salazar who writes his thesis on the topic.
For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as
defined in RFC 2710, is “to enable each
IPv6 router to discover the presence of multicast listeners (that is, nodes
wishing to receive multicast packets) on its directly attached links, and to
discover specifically which multicast addresses are of interest to those
neighboring nodes.” MLD was updated by MLDv2 in
RFC 3810 in order to “add the ability for
a node to report interest in listening to packets with a particular multicast
address only from specific source addresses or from all sources except for
specific source addresses.”
Taking the chance from
a discussion
on the
IPv6 hacker’s mailing list
and the
freshly proposed draft RFC
regarding
the deprecation of the generation of IPv6 Atomic Fragments,
I decided to test very quickly what is the current status related with the
latest and some of the most poplar Operating Systems (OS) status (whether they
send Atomic Fragments in response to Packet Too Big messages, or not). The
motivation behind this was to check which one of them is potentially vulnerable
to the DoS attack using the technique described in the above proposed RFC and
taking it for granted that Atomic Fragments are blocked in the real world (but
more about this, in another blogpost in the near future).
Last week we had the opportunity and pleasure to present some of our research
results at BlackHat US 2014 (besides of meeting a lot of old friends and having
a great researchers’ dinner).
Enno and Antonios gave their presentation on IDPS evasion by IPv6 Extension
Headers, described
here.
The material can be found
here: Slides,
tools (the main tool used was Chiron,
authored by Antonios) &
whitepaper.
Ayhan and me presented our results of the security analysis of Cisco’s
EnergyWise protocol. The protocol enables network-wide power monitoring and
control (ie turning servers off or on, putting phones to standby — basically
controlling the power state of all EnergyWise-enabled or PoE devices). The main
problem (besides a DoS vulnerability we found in IOS, see
official Cisco advisory)
is its PSK-based authentication model, which enables an attacker to cause
large-scale blackouts in data centers if the deployment is lacking certain
controls (for example our good old favorite, segmentation…). There will be a
longer blogpost/newsletter on this topic soon.
The material can be found
here: Slides &
tools
In the
“A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices”
blogpost I described a way to evade a high-end commercial IDPS device, the
Tipping Point IDPS (TOS Tipping Point, Package 3.6.1.4036 and vaccine 3.2.0.8530
digital), by abusing a minor detail at the IPv6 specification. As I promised at
the end of that blogpost, this is not the end. In this blogpost I am going to
describe several new and different ways of evading another popular IDPS, an
open-source one this time, Suricata.