A while ago I wrote a short paper laying out options for an enterprise organization to get global IPv6 address space from the RIPE NCC, discussing the advantages and disadvantages of different approaches. As I think the topic may be of interest for others, too, I’ve distilled an anonymized version. It can be found here. I hope some of you find it useful.
As you may remember, back in 2014 we published a whitepaper (compiled by Antonis Atlasis) on the support of IPv6 in different pentesting tools. This is almost three years ago and we thought it is time for an update. In short not much has changed. Most of the tools which didn’t support IPv6 are still not supporting it or haven’t got any update since then.
This post will cover the tools where we could identify some progress on supporting IPv6.
Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may refer to this post or to this talk from the Troopers NGI event).
Some of this has already been discussed in RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls but that document is from 2007 and things may have changed in the interim.
Let’s start with a quick look at the traffic which might be of interest. We will take a server perspective here, read: which types of IPv6 traffic might have to be accepted by a host/NIC firewall in order to support proper operations? I will discuss the following, with a focus on the implications of filtering them locally:
A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M” version 15.2(2)E4 connecting
A Linux based attacker system running Chiron and
A FreeBSD target system, running different OS versions and configurations and
A Linux based laptop running a control script that remotely performed the necessary tasks on the two machines mentioned above
The main question was: Would the impact on the target system and the possible attacks that were observed with the Windows Server 2016 victim be reproducible on other operating systems? Or would those behave totally differently?
27 April 2016 marked a turning point for a lot of countries as well as a lot businesses worldwide: EU regulation 2016/679 (going by it’s more widely known name General Data Protection Regulation and abbreviated GDPR) was adopted by the European Parliament, the Council as well as the Commission [1]. Especially readers from countries outside of the EU might ask “Why should this be of interest for me?”.
The point is: if your business is dealing with data of EU citizens (e.g. because you are having an online shop selling goods in the EU, or you operate a social network platform with customers that are EU citizens) you are liable under GDPR – this is regulated in Article 3, section 2 of the regulation: “This Regulation applies to the processing of personal data of data subjects residing in the Union by a controller not established in the Union, where the processing activities are related to: (a) the offering of goods or services to such data subjects in the Union; or (b) the monitoring of their behaviour.”
I’d guess that if you are reading these lines you become aware (if not have been so before) that your business might most probably be affected by GDPR as well. Now, the purpose of this blog post is not to enlighten you on the basics of GDPR but to discuss one special, interesting aspect of this regulation: pseudonymisation and how it might support your way to become compliant with GDPR.
Last friday Florian and me attended the 6th No-Spy Conference in Stuttgart, Germany. We gave a talk about surveillance and censorship on modern devices in North Korea and discussed various aspects with the attendees. The atmosphere was very welcoming and we had some nice discussions about various topics which allowed us to better clarify some things. The slides are available here.
I’m on my way back from the RIPE74 meeting in Budapest. It was a great event: quite a few nice technical talks in the plenary, productive working group meetings and some really good hallway discussions.
Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!
Here’s some stuff I found particularly interesting:
Andrew Alston’s take on “Anti-Shutdown Policies” (slides and video incl. extensive mic discussion)
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.
Troopers ’17 – the 10th edition – madness is over and hopefully all of you are well rested and recovered after this special week. Of course the rest of the world did not stand still and thus Google lifted the curtains on a new public portal collecting and promoting the Open Source Software projects developed by employees of Google: opensource.google.com. There are a lot of interesting projects that might incubate new interesting developments. And even security oriented tools and projects (51 at the time of writing to be precise) are publically available [1].
In the recent post on the IPv6 properties of the latest MS Windows versions I announced another one providing details on the RFC 6980 related testing I had performed. So here we go.
When doing IPv6 security testing there’s mainly four toolkits which can be used:
Scapy (whose IPv6 capabilities are, afaik, mainly maintained by Guillaume Valadon. some tutorial on IPv6 packet crafting with scapy can be found here).
Each of them has specific strenghts & limits, which will not be discussed here. For the testing I performed I chose Chiron as it has the most powerful options when it comes to IPv6 extension headers and fragmentation.