A Short Teaser on My New IPv6 Testing Framework

This is a guest post from Antonios Atlasis
==============================

Hi,

my name is Antonios and I am an independent IT Security Researcher from Greece. One of my latest “hobbies” is IPv6 and its potential insecurities so, please let me talk to you about my latest experience on this.

This week, I had the opportunity to work together with the ERNW guys at their premises. They had built an IPv6 lab that included several commercial IPv6 security devices (firewalls, IDS/IPS and some high-end switches) and they kindly offered their lab to me to play with (thank you guys 🙂 – I always liked …expensive toys). The goal of this co-operation was two-fold: First, to test my new (not yet released) IPv6 pen-testing tool and secondly, to try to find out any IPv6-related security or operational issues on these devices (after all, they all claim that they are “IPv6-Ready”, right?).

But first, what is this tool all about? If I would be asked to summarise in one sentence the most important feature of this tool, this is that it allows you to build completely arbitrary IPv6 header chains very easily. Doing so, you can test on your own the IPv6 support of devices and platforms, or even pen-test them. One requirement though: No, there are no license fees (it will be released under GPL), but you have to know what IPv6 is and how it is used. That is, this tool is not for script-kiddies (go out and play with other toys boys, this new toy has the IPv6 RFCs as a manual). The advantage of it is that it is so flexible that its capabilities are actually limited by the user’s imagination. For example, instead of incorporating some known or even some less-known evasion techniques, it allows you to find your own ones (you just have to know IPv6 and imagine how to (ab)use it)!

Then, there were our IPv6 security devices (or, our “targets”, as it used to say in these cases), all commercial ones. As I have already said, these were my toys. It was really interesting to see what an “IPv6 Ready” product is. And much more interesting, to check the balance between RFC-compliance and security-orientation (because these two things do not go side-by-side, some times). So, we started using their default configuration and checked what IPv6 features support and if these could be abused. Then, we enabled some of the missing IPv6 features (because some of our toys were …cheating – security vs. functionality) and tested them again. We created several scenarios. How well they protect you from IPv6 attackers. What IPv6 configuration capabilities they offer. How you can configure them to increase your chances in surviving in the IPv6 wild world. And of course, can they be abused? Can they be evaded?

The results? I am not going to give you any detail rights now, but I can tell you that, apart from any operational issues, while many of them appear to have a quite stable and “secure” IPv6 behaviour, under very specific circumstances they appeared to have some security issues too. However, interestingly enough, there were also cases that an attacker could make them completely “blind” (aka, circumvent them) and hence, pass through malicious traffic. Remember: As I use to say, when you break layer-3, you can break everything above it.

You want more on this? OK, see you at the IPv6 Security Summit at Troopers 14, in the beautiful city of Heidelberg!    

Cheers, Antonios