As you may know, we published a
whitepaper
discussing the behavior of different operating systems once they receive IPv6
configuration parameters from different sources two years ago. At that time, the
results were quite a mess. We were curious whether the situation is still so
“dire” like two years ago. We fired up the lab, updated the tested operating
systems and performed the tests again.
To summarize, at least in scenarios were only one router is involved, the
results look way more consistent (even cross operating system) then two years
ago. So we made progress on this front. Unfortunately, as soon as a second
router is introduced into the segment it gets messy and the operating systems do
show inconsistent behavior.
It is a pleasant surprise for many (us included) that Microsoft implemented
support for the RDNSS (RFC 8106) option
in Router Advertisements beginning with the
Windows 10 Creators Update.
Interestingly, I wasn’t able to find any official documents from Microsoft
stating this. As we are involved in a lot of IPv6 related projects for our
customers, the lack of RDNSS support for Windows and DHCPv6 for Android is a
major pain point when implementing IPv6 in mixed client segments, as you need to
implement both mechanisms to ensure that all clients do get the relevant network
parameters. I won’t beat on the dead horse, but Microsoft’s decision is a huge
step in the right direction and one can hope that one day Google finds a
“compelling use case” to implement at least stateless DHCPv6 for Android.
Since BlackNurse was released on 10th of November, we asked ourselves whether
this problem does also apply to ICMPv6 traffic. To answer this question,
Christian Tanck (one of our students) build a lab with several firewall
appliances. Kudos to him for testing and the following blog post.
Intro
On 10^(th) of November, 2016 the
TDC Security Operations Center in Denmark
published the BlackNurse Denial of Service Attack Report as an
PDF download on their website and
a
blog post
written by Erik Hjelmvik from NETRESEC. He was involved in the project by
helping with the analysis of packet dumps, testing different systems, with ideas
for test scenarios and at least inspired me with his blog post on how to build a
test lab described later in this post. The attack on its own was discovered by
the TDC analysts Kenneth B. Jørgensen and Lenny Hansson.
As you may have already noticed, Cisco released an urgent
security advisory
describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of
Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA
and “classic” IOS are under investigation. At first glance, it might look like
yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an
unauthenticated, remote attacker due to insufficient processing logic for
crafted IPv6 NDP packets that are sent to an affected device. Following the
public discussion about the vulnerability, it seems that these packets will
reach the, probably low rate-limited,
LPTS filter/queue
on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for
IPv6 traffic, or in general a high CPU load as these packets will be processed
by the CPU. More details are currently not available, but this might indicate
the affected systems aren’t doing proper message validation checks on NDP
packets (in addition to the LPTS filter/queue problem).
Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))!
After things have settled, I want to take the opportunity to reflect my thoughts
and impressions on the IPv6-only WiFi we had deployed during the conference. To
make sure that everybody is on the same page let’s start at the beginning.
In the last couple of years we had provided Dual-Stack connectivity on the main
“Troopers” SSID but also had an additional IPv6-only SSID. This year we decided
to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while
providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a
feeling how many clients and applications can work properly in an IPv6-only
environment. We intentionally didn’t announce it vastly beforehand, hoping that
attendees would just connect to the main SSID without noticing anything. We were
aware that some applications might expose issues but, as I said , we wanted to
get a feeling to which degree problems actually occured.
today we want to examine the behavior of Cisco devices when they receive spoofed
IPv6 Neighbor Advertisement packets from an untrusted system pretending to be
the default router for the local segment. We start with a quick refresher how
Cisco devices behave in the legacy (IPv4) world when they receive a spoofed
broadcast ARP packet containing the IP address of the device but with a
different MAC address, followed by a discussion of the corresponding behavior in
the IPv6 world.
Enno and I spent the first day on Cisco Live Europe in Berlin today attending
the “Advanced Practical Knowledge for Enterprise Deploying IPv6” technical
breakout held by Tim Martin and
Jim Bailey.
It was a good breakout session, and thanks again Tim for the honorable mention
of our work in your slides! We really appreciate it. Like
last year,
we were curious how the Wifi network was setup this year as I face a
corresponding task for Troopers in March,
with some
major changes
in comparison to the last years. The Wifi infastructure in Berlin looked very
similar to the one from last year in Milan, we had the “standard” Cisco Live
SSID as well as an IPv6-only (with NAT64 as translation mechanism) SSID. The
standard SSID looked identical to last year with the exception that now the
RA Throttling
feature on the WLC was active from the beginning! Neither the M nor the O flag
are set which means that my client has to use the legacy protocol to resolve
AAAA records. As I am running Windows, it does not support
RA option 25 but the option wasn’t
included in the RAs anyway. The preference was configured to the default
“medium”. One thing I noticed, but haven’t had a chance to ask
Andrew Yourtchenko, was that for the legacy
(IPv4) connection they use HSRPv2 as an FHRP protocol (indicated by the MAC
address
00:00:0c:9f:f0:01
I received from the gateway) but for IPv6 I received Router Advertisements from
two different MAC addresses (which both belong to Cisco, so I don’t think anyone
sent spoofed RAs). I am curious about the reasoning for this approach 🙂
What i also encountered was that the Peer-to-Peer Blocking feature was
apparently not enabled on the SSID as I was able to enumerate approx. 1600
active clients at the time. No worries, I haven’t done anything else, just was
curious whether the feature was activated or not…
It’s me again with another teaser for an upcoming workshop at the
IPv6 Security Summit. This one
is a classic! If you happen to deploy IPv6 in your environment in the near
future, but didn’t had the time to think about the security implications, this
workshop
is the right place to start.
We will start the workshop with a quick refresher of the core behavior of IPv6
to make sure that every attendee is on the same page. Before we start discussing
and demonstrating various IPv6 attacks, we dive into (a little more abstract)
topic of why IPv6 security actually isn’t that easy to implement. We will
continue with IPv6 attacks targeted at the local link. Rafael and I will
introduce commonly used IPv6 attack tools as well as performing various attacks
in a dedicated lab environment. Every attendee is encouraged to participate in
these exercises. We will provide you with the necessary tools; you just have to
bring a laptop with (ideally) Linux installed. We will prepare some virtual
machines including VMware Player in case your corporate laptop runs Windows.
today I want to talk about OSPFv3. I won’t cover the glory details of
OSPFv3, there are smarter guys than me out
there who did that
already 😉 and
there are great resources to familiarize yourself with the protocol. However, it
should be noted that OSPFv3 is not only OSPF for IPv6, OSPFv3 brought some major
enhancements compared to OSPFv2. Wouldn’t it be cool to benefit from the
enhancements in the IPv4 world as well?
Today I want to give you a little teaser about my upcoming talk at the
IPv6 Security Summit about
First-Hop-Security on HP devices. In the past I presented on about
First-Hop-Security in the
Cisco realm and
in virtualized environments.
Until recently, Cisco was mostly the only vendor who had a sufficient
implementation of various IPv6 security features on their access-layer switches,
but HP closed the gap considerably and it’s time to have an in-depth look
at their implementation of those features.
