End of internship

This will be my last blog post in this particular blog (for now at least) since my internship ends today. It has been a great 13 weeks of working here with a lot of learning experiences, not only about IPv6 security but also about IT security in general. As I never looked from the vantage point of security before, I can now say with confidence, that this internship had a huge impact on me on that regard & I even want to persue a career in IT security now should I get the chance!

First of all I would like to thank my mentors at the internship, Dieter Vandenbroeck & Roel Vansteenberghe, for giving me the opportunity of doing my internship here.

I would also like to thank the 2 other interns for their support, so Yannick Stevens & Jan "Mr. BigShot" Weyens thanks for the support and good luck at working at EY!

Last but certainly not least I would like to thank all the other colleagues for their help, certainly in the first few weeks, and support on the subject.

Regretting the end of the internship I now close this chapter in my life and the blog post!

-- Kevin Wille

Test Results: Firewall Rules Set

In this last real technical blog post we will discuss the test results with the firewall rules in place on the OS. In Windows distributions this is just the standard firewall. In Linux I used Ip6tables and for FreeBSD ipfw. We still want to have good IPv6 connectivity so it's not the intention to block all "dangerous" traffic and have no auto configuration or anything anymore. We will try to accomplish this by denying all traffic and whitelisting all trusted traffic. The rules we added are discussed in the previous blog post. Keep in mind variations of these results are always possible if some of the rules used are modified.

UNIX

Scanning

Since ICMPv6 Response & Request messages are blocked by ipfw, none of these scans went through.

DoS

All floods except for the DAD attack were let through. This is because while not all traffic is let through. RA's/NA's are limited to the default router/local traffic but they still have to check these packages. So when a flood is in effect, they have a lot less load increase but it is still present (about 20-30%) per DoS.

MITM

None of the MITM attack work anymore. This is because we limit RA's to only be accepted from our default router, and NA's only for local traffic.

LINUX

Scanning

Since ICMPv6 Response & Request messages are blocked by ip6tables, none of these scans went through.

DoS

Because in Linux we can limit the traffic allowed through for specific packets, we did this for RA's and NA's to be limit to 10 packets per second. This meant no DoS attacks had any real impact.

MITM

All distributions tested blocked all MITM attacks except for Ubuntu. Ubuntu got spoofed with the NA/NS MITM attacks.

WINDOWS

Scanning

Since ICMPv6 Response & Request messages are blocked by ipfw, none of these scans went through.

DoS

All DoS attacks still worked on all OS's because in Microsoft the amount of packets cannot be limited. Because of this Microsoft OS's are still susceptible by DoS Attacks.

MITM

None of the MITM attacks work anymore. This is because we limit RA's to only be accepted from our default router, and NA's only from local traffic.

Conclusion

After implementing some basic firewall rules we can conclude that most malicious traffic can be stopped. Of course for some platforms of OS's additional software or an additional firewall still should be implemented to try and completely block all malicious traffic. In Linux and Unix enough configurations can be made to limit all incoming traffic. While in windows you cannot.

There are of course many other ways to implement IPv6 security, and it is always best to check for BCP that are relevant to the security measures one wishes to implement. e.g. The following link discusses BCP's for ICMPv6 messages in firewalls.

http://tools.ietf.org/html/draft-ietf-v6ops-icmpv6-filtering-bcp-01

Securing OS's againt IPv6 attacks

In this blog post we will overview some firewall rules to protect a specific OS against IPv6 threats. It is a given these should be some form of last resort since normally a perimeter firewall should be in place alongside an IDS or RA Guard. Because the configuration of these devices fall out of the scope for the internship they will not be discussed here. It can be noted however that all firewall rules reviewed in this blog post should be applicable to a perimeter firewall.

The configuration for these rules will be divided into Windows XP, the rest of the windows distributions, Linux Distributions and Unix.

Windows XP

Not much can be said about windows XP, since no extra firewall rules can be added. IPv6 is supported in the firewall configuration but these configurations run alongside their IPv4 counterpart. Meaning that ICMPv6 request and response are blocked but RS/RA, NA/RA or other IPv6 protocols that don't exist in IPv4 will not be affected by these firewall rules. If wanting to use Windows XP in an IPv6 network it should be secured by other firewalls since it's base firewall is not compatible enough with IPv6 to be effective.

Windows versions

All the rest of the tested windows versions (vista, 7, 8, 8.1, 2008, 2012) have the same firewall configurations so the same rules apply for each OS. Assuming only one router is present in the network, we'd want to limit getting router advertisements from anywhere but the router. This should be done on the local level for extra security. This can be achieved by going into the advanced firewall configuration, setting both incoming and outgoing traffic to deny and finding their respective RA/RS configs. You will also notice that most ICMPv6 types are allowed through on default even if in/out traffic is denied. Disable the rules of the ICMPv6 traffic you do not need or limit them to at least the local network. In our case, none of these were needed so we disabled all the extra rules.

Now for the RA/RS rules, you don't need to change anything except for the range. You will have a global and a local range. Since we only want RA/RA messages from our local network (only the router), you set the global range to "specified range" but don't fill in any range. For the local network you should do the same but here fill in a single address: the LLA address of your default router. You can also specify the global address of the router, but only the LLA should be enough.

Next up are the NS/NA messages. It is optional if you want to enable these if other traffic is allowed on the same private network, but since we don't want to limit every functionality of IPv6, only restricting it should be fine. In Windows it is not possible to limit the rate of packets coming in so be careful who you allow through. In our example we allowed NS/NA traffic from the local network, which is not ideal since a breach of the local network would nullify these rules. For the NS/NA rules, we specified on the local part that only traffic from and to fe80::/10 should be allowed.

These are all the firewall rules that should be changed in our setup for the attacks we tested. Almost all of the MITM / DoS attacks use these protocols and so should be limited.

Linux

In the Linux distributions the IPtables were used to restrict traffic through our network. A lot of these distributions have GUI versions for these IPtables, but these can be different in each version. So since IPtables are the core for all distributions, it is easier to use this.

First of all set the default policies to drop (by default they are set to accept) and flush them just to be sure. Normally now all traffic should be denied. We will take the same approach on which traffic to accept as with windows, only iptable rules can be modified more detailed and complex. First of all we would want to accept traffic from our default router. This can be done by allowing traffic from it's LLA to our system. e.g.
ip6tables -A INPUT -s fe80::a00:27ff:ff27:00a -j ACCEPT

With these we allow all trafiic from our default router. This ensures that the only RA/RS messages accepted will be those of the default router.

The NS/NA messages will also only be allowed from our local network but are limited.

ip6tables -A INPUT -s fe80::/10 -p icmpv6 --icmpv6-type 135 -m limit --limit 5/sec --limit-burst 10 -j ACCEPT

This rule will ensure the use of the NDP but will also make it harder for attackers to flood our system with NA/NS packets.

Of course all these rules should be reversed at the output rules where -s (source) is changed to -d. Else the host will receive those packets but will not respond to them.

UNIX

FreeBSD has no IPtables like the linux distributions, but has IP filter /IP Firewall which are very much alike to iptables. As with the Microsoft and Linux distro's we will restrict all traffic from and to our system by only allowing traffic from the default router. A slight mix-up here in FreeBSD is that it does not support to specify NS/NA yet (with ipfw) so we a)block all traffic like usual but we can't add an allow NS/NA rule so NDP does not work anymore or b) we accept all icmpv6 traffic. I think it is safe to say for the purpose of these tests that we shouldn't allow all ICMPv6 traffic... You can however allow all ICMPv6 traffic and then block the specific ICMPv6 types that are available to overlap with each other.

An example of this is when we block RA/RA messages from the local network. You will notice since this is not iptables anymore, that the syntax is a little different for FreeBSD. First things first, we need to enable the firewall in the /etc/rc.conf. You add these sentences to the file:

firewall_enable="YES"
firewall_script="YES"
firewall_script="/etc/ipfw.rules"

These allow the firewall to be enabled on boot, and allow us to load a script with our firewall rules on load. You specify the rules you wish in the file /etc/ipfw.rules. Do not forget to flush ipfw first in the script, else there might be problems with the default rules.

An example of blocking RA/RS messages:

ipfw add deny ip6 from fe80::/10 to any icmp6types 5,9,10 in

These icmp6types can be found in the types list on the manpages of ipfw.

Conclusion

As we can see, these firewall rules can be a reasonable line of last defense in case the perimeter firewall is breached, but still most of these rules are to incomplete to work effectively. Most of the time some sacrifice has to be made either security wise where some protocols you do not wish to pass that do pass or where some protocols (like NDP) that you want to let through but can't. The most complete rules are those of the iptables since these have the most options available plus they can limit the rate of the packages let through. Unix is not bad either, but is more complex.

Test Results: Default Firewall

Like my previous blogpost, I will discuss some of my findings during my tests of IPv6 networks where the systems have their default firewalls enabled. The same OS's will be tested with the same attacks. These tests are made so we can have an insight at how well networks would handle attacks once the perimiter firewalls or IDS is bypassed. Note that these tests work with the assumption of an IT administrator that just left the default values as they were in the firewall regarding IPv6. The IPv4 part of the firewall can very well be adequatly protected.

Another thing to note is that most Linux OS's do not have any default rules whatsoever. Linux distributions work with IP tables. On the distributions I tested, these allowed everything. One more point of interest is Windows XP. Since it does not support IPv6 natively and had to be installed, by default no firewall rules were in place for the IPv6 network. This is adjusted since Service Pack 2 where IPv6 firewall rules are grouped under IPv4 firewall rules. This means that traffic that both IP's use will be subject to these firewall rules while the others will not. E.g. Echo Request and Responses (pings) will be blocked since both IPv4 and IPv6 make use of them. RA, RS, NA and NS messages on the other hand will not be blocked.

UNIX

Scanning

FreeBSD uses the ipfw (IP firewall) which is not enabled by default, but can be enabled with some default firewall rules in place. Most rules allow traffic on the local level but not on the global level. For scanning this is the most interesting path anyway. There are two rules however that only allow some ICMPv6 type messages to get through on the global level. These being 1,2, 135, 136. This means that for our scanning tests, the scans failed. None of the scan tests tested managed to find the FreeBSD Host

DoS

Since the DoS attacks work both on the global as the local level, none of the DoS were effectively blocked.

MITM

The NA and redirect MITM attacks did fail this time around since the redirect I tested used global addresses. Normally NA MITM should be successful but as this is a local MITM attack, and the firewall only allows the packets with a global address through, this attack also failed.

LINUX

As stated previously in Linux distributions no real default rules are added. The IP tables let all traffic through by default.

WINDOWS

Scanning

As expected, just like with the IPv4 firewall rules, all Echo Request/Response packets are blocked by the default firewall. So all the ping scan tests failed. On the portscan however, Windows 7, 2008 and 2012 still had ports open. (port 5357)

DoS

No Windows system actively blocked one of the DoS attacks. This can be verified by looking at the firewall rules, where the inbound rules state that almost all ICMPv6 traffic (except for pings) is allowed through.

MITM

Same as with the DoS attacks, no system actively blocked more MITM attacks then they already did (or didn't).

Conclusion

While Linux systems generally handle IPv6 traffic a little better than Microsoft systems (e.g. during floods), their default allow-all rules obviously did not help in these set of tests. Of course one can argue that most IT administrators that use Linux distributions generally know what they are doing and would not leave the "default" firewall rules (in this case IP tables) the same.

FreeBSD did very well on this test, with the pleasant surprise of at least some form of IPv6 rules that made some attacks impossible. Still Floods can be the most disruptive (and hard to deflect) attacks, these all still worked.

Microsoft had no real surprises other than that they blocked pings. Almost all other ICMPv6 traffic was allowed through making the effort of blocking the pings obsolete.

In general it is safe to say decent firewall rules are not widely used yet because IPv6 is not as common as IPv4 yet. One can argue however, that those who make the transition to IPv6 (or use dualstack) generally know what they are doing and at least implement some basic firewall rules

Test Result Overview: No Firewall

In this blogpost I will give a quick overview of my test results when testing attacks on an IPv6 network where the victim systems have no firewall enabled. The purpose of this test is twofold: to see what the attacks can do on different systems if the firewalls could be breached and disabled. Furthermore this test serves as a baseline for further tests. It's also important not to assume every IT administrator leaves at least his default firewall on, now can we? It probably occurs that IT admins rely heavily on their perimeter firewall/router to fend off the bad guys and run into less problems by just disabling the firewall for the private networks.

I will not go into detail on these test results, but will give more of an overview with the most interesting results. The OS's tested are divided into 3 groups. The first group is UNIX, which only consists of one OS's, FreeBSD 10.0. The second group is Linux which includes Debian 7.4.0, Ubuntu 12.04, Fedora 20 and CentOS6.5. I chose these to try and cover quite a large range of distro's, since most other are related/derived from these. The only exception to this are the SUSE distro's which I did not include in these tests yet, if enough time is lefover after the final tests SUSE will also be tested. The last group of course is Microsoft, its ease of use and widespread use makes that the most OS's that are encountered in the wild will be from Microsoft. These include Windows XP SP3, Vista SP1, 7, 8, 8.1, server 2008 R2 and server 2012. These are chosen because I think these are the most common versions out there. The SP ratio might seem random, but I used what was available to me.

The attacks itself I will divide into 3 groups: Scanning, since it is no use trying to access a network if you don't know the addresses of the victims. DoS because this can cause severe problems if used on a server and MITM which includes maybe the most dangerous attack of them all.

UNIX

Scanning

Here I tested a portscan, a general scan of the network, scan on known OUI, IPv4 or sequential addresses. As expected, without any firewall this is like shooting fish in a barrel. Because I left the IPv6 address to the distribution of the router, the system generated an IPv6 address based on the OUI of the virtual software. It also uses the same address every time it boots. All tests were successful in finding the victim except for the one where I searched based on IPv4 embedded addresses. As I said these results were expected since no firewall stopped ICMP traffic

DoS

As I researched some of the attacks (like RA flood, smurf, NA flood, NS flood) many sources claimed that RA flood is fended off by Linux and Unix systems' IP stack and thus should not have that great an effect. Well tests proved otherwise: while only the RA flood completely froze the system, the other ones also had huge load increases ranging from 50 to 80%! If you know that FreeBSD is exclusively used as a server, which may or may not run under a very high load already, you can easily spot the problem.

MITM

In this category FreeBSD scored better than in the previous tests. I tested MITM attacks with spoofed RA's, spoofed redirects, spoofed NA's and the dreaded SuddenSix SLAAC attack. The redirect is indeed successful, but the malicious packet should constantly be resent if this is to work efficiently, else the system discards the redirect. Spoofed NA's completely did not work. Spoofed RA's did work but the greatest surprise was that the SuddenSix attack did not. This is because FreeBSD has to be completely configured manually, IPv6 addresses can be acquired dynamically (via RA's) but IPv4 addresses cannot (at least not with a lot of tinkering). So FreeBSD might accept the packets sent out by SuddenSix, but just doesn't handle them since it only knows to set and IPv4 address statically (which again, is part of its exclusive use as a server, it has no need of dynamic addresses)

LINUX

Scanning

The same as with the UNIX systems, most scans worked except for the  IPv4-embedded one. Only Ubuntu and Fedora had the exception of even with no firewall enabled, no open ports could be detected.

DoS

Where Fedora scored "best" on in scanning, it dropped the ball on the DoS. ALL of the DoS attacks worked on it. None of them actually caused it to freeze, but all of them made them run VERY slow and thus unworkable. CentOS on the other hand performed excellent! Even without any firewall rules whatsoever, only the smurf attack used up a few resources. All other DoS attacks did not manage to increase the load by even 10% or didn't do anything at all! Ubuntu and Debian on first glance did not fall for the RA flood, as only 10 addresses or so are accepted and added to the NIC so no freeze BUT it disconnects the systems from the network which is also a DoS.

MITM

As good as most of the systems scored on the DoS tests, none of them scored well against the MITM attacks, on every system, every attack worked or at least spoofed some addresses in the neighbor cache. This is because while they are protected against floods, the MITM attacks are no different from real traffic and are only sent out periodically.

MICROSOFT

Scanning

Windows actually performed better than expected on these tests because of the way the generation of an IPv6 address is implemented. When windows systems generate their IPv6 addresses, they actually generate 2, one "set" addresses that stays after reboot and a temporary address that is different every time. If you scan the network the only address you get to see is the temporary one which makes it a little harder for attackers to continually attack those systems since they have to recheck the addresses every time the systems are rebooted. Also, the OUI scan where all Linux and UNIX systems failed, does not work for windows since their addresses are not based on the OUI of vBox, they only exception for this is windows XP. Still except the OUI scan all other scans worked, but it is nice to see, some measurements are taken to at least make it a little harder for attackers.

DoS

No real surprises here, almost all systems are affected by all the attacks (even the smurf attack, which is described to only work on Linux based systems) with only a few exceptions, Windows 7 and server 2008 are not affected by the NA flood whatsoever, and windows 8.1 is not affected by the NS flood. RA flood completely freezes every system except for windows 8.1. Windows 8 and 2012 do run normal again after the attack is stopped, while all other systems have to be rebooted (sometimes manually!) for them to work normal again. Also there is no hope for improvement of the RA flood on the older systems as security researcher Sam Bowne tested this attack against many different systems, and notified the manufacturers (in this case Mircosoft) but Microsoft coldly responded with something along the lines of: we will only "prevent" this attack for windows 8 and further ( if you can call causing them to freeze or have a constant CPU load of 100% preventing it...) and older systems will not receive this treatment, meaning they will continue to be affected by it. [1]

MITM

Also had the expected results where most of these attacks did work and route all IPv6 traffic through the attacker EXCEPT two systems. Since XP does not have IPv6 support "out of the box" (you have to enable it) it does not completely handle some packets right, an NA MITM does not work on XP because it does not respond on NA from other systems. It only sends out its own NS on the network and only responds on those. If this shortcoming is good or bad is open for discussion, on the one hand it is not affected by that attack, on the other it only acts that way because it does not know how to handle NA records properly... All other MITM attacks do work however.
The second and greatest surprise is Windows 7. This OS is completely unaffected by the SuddenSix attack. It still baffles me why and how it does not work on this system alone. Win 8, 8.1, server 2008, server 2012 are all still affected by it and ONLY windows 7 not. It does not get a spoofed IPv6 address, no router entry for the attacker nothing. I have searched the internet far and wide as to why it isn't affected but could not find out why. Is because of my setup? It could possibly but all other systems are setup exactly the same way... Is it because it is a virtual machine? All others are too... Did I configure something wrong? Possibly but since I just had to disable the firewall, I cannot see why I did misconfigure. It also accepts IPv6 traffic in the settings, and does gain an IPv6 address automatically when given out by a router so why does it not work? All other MITM attacks DO work on Win 7, it is only the SuddenSix one that doesn't...

Conclusion

While many of these results are expected some OS took me by surprise. Unix and Linux systems performed as expected from research with a few exceptions, but for me it is windows that takes the cake. Microsoft can implement some good ways to deter attackers (IPv6 address not based on OUI, also generate a temp address that is the only one picked up by scans) and on the other hand, they completely ignore some more pressing attacks like the RA flood (except on win8 and further). They also have the most "flukes" if you can call it that with WinXP that does not (always) respond to NA's because of an implementation error (probably) and Win7's complete disregard for the SuddenSix attack!
Of course more interesting results will follow when the default firewalls are actually turned on.

References:
Cisco Press: IPv6 security by Eric Vyncke
http://samsclass.info/ipv6/proj/RA_flood2.htm
SI6 toolkit by SI6 Networks
THC Toolkit
Scapy tool
SuddenSix script by Neohapsis Labs

Progress of the internship

This week the blogpost will summarize my time here up until now at EY. This is because the internship in now more or less halfway done. I will elaborate on my steps until this week and how/why I did it that way.

Step 1: Research

When the internship just started, I only knew the basics of IPv6 networking. In the class ANT we had seen how IPv6 worked, the different kinds of addresses, how an IPv6 packet looks like, etc. Still security is a whole other branch where those basics should be common knowledge so you at least understand when a specific test works or doesn't work.

My teacher M. Vansteenberghe lent me a book about IPv6 since this expanded more on the subject and frankly, the class about IPv6 was almost a year ago so I knew I had to refresh the subject before starting my internship. When the book was finished, I also started collecting information I could find to gain a headstart when starting at EY

When starting my internship, my biggest help would have been the cisco book of Eric Vyncke: IPv6 Security. This covered alot of the security issues I now test and as also described how one could try to prevent such an attack on the network. I viewed many other sources like the RFC's about IPv6/ Neighbor discovery and so on.

Step 2: Choosing the toolkits

When researching for the different kinds of attacks, I also had to consider how to test them. Alot of the "attacks" or security breaches I found did not have enough information on how to test them on your own network. It would of course be probematic if I only researched  2 or 3 highly complex attacks that may or may not fault any network, secure or non-secure when at the same time I could research many different smaller attacks that may be more common.

The toolkits I needed if found rather quickly, THC IPv6 Attack toolkit has the most tools to test with and is easy to use. SI6 IPv6 was another known toolkit which had fewer attacks to test, but were more complex and could be more expanded upon. E.g. the scan in THC "alive6" just scans the local network, while the scan6 tool of SI6 can scan for various options like embedded IPv4 address, OUI, sequenced numbers, etc. My last major tool would be scapy. Very handy for getting a closer look at the specific packets and is used to test those few attacks that THC and SI6 did not cover (E.g. RHO or Router Alert).

Step 3: Setting up the test environments

After the research was done and my documents about the tests were done, it was time to think about the environments where to test them. They had to be light on the CPU load since most of it is tested in a virtual environment. With this I also had to make sure the test networks were small as I would overload the CPU otherwise. Eventually I went for simple networks where a router deals out the addresses, a switch and a victim. And of course our attacking computer.

A router would ideally have been a cisco router, since this gives the most options to later expand on security, but was hard to accomplish since again, it would take up alot of resources and not every cisco router is available to me nor has every cisco router IPv6 support. The choice was made to use pfSense which acts as a router and a firewall.

When the test environment was set up, all that remained was to set up all our devices. Most were just the typical install and wait theme, but for others like pfSense, a little documention was required.

Step 4: Testing the environments

Right now I am in the middle of testing so I will not disclose to much information as of yet (wait for further blog posts!). But I will disclose my 3 typical scenario's. First of all, all the attacks will be tested against an OS with no firewall enabled. This is mostly to look which OS has bugs in their TCP/IP stack by default or which OS handels the attacks the best. Otherwise there are still alot of IT admins that just disable their firewalls (or in case of some linux distro's don't configure them) so traffic flows more freely and they don't encounter many problems.

The second scenario is the same tests against the same OS's but this time with their default firewall settings. Even more common then IT admins disabling their firewalls or IT admins simply leave the defaults on because it will be enough "as is". Of course most of these OS's have reasonable firewall rules so that you are more or less "safe" in an IPv4 network, but there is the catch, since IPv6 is different, or they have no IPv6 specific rules (like rules for NA/RA/) or they are badly configured.

The last scenario is those same tests against a network and hosts that have the BCP (Best Common Practices) enabled. So that means the correct firewall rules, manual IP addresses (if possible, in larger networks this might not work out) and then some! This will be the most important test to see which attacks are actually the more dangerous ones to look out for in an already secure network.

Conclusion

The internship has been fun and very interesting up until this point, I personally think it's great to think about the security aspect of networks and such and having the opportunity to test and improve those networks. Of course my research here is not ground breaking, all these attacks are known  already and tested properly but I found it hard (at least at the time of writing) to find a complete "guide" with multiple toolkits. Also little information is found on how these attacks react to different kinds of OS's and versions of those OS.

References:
- Cisco Press: IPv6 Security by Eric Vyncke
- THC IPv6 Toolkit: https://www.thc.org/thc-ipv6/
- SI6 Networks IPv6 Toolkit : http://www.si6networks.com/tools/ipv6toolkit/
- Scapy : http://www.secdev.org/projects/scapy/

IPv6 Header Manipulation Part 2

In our previous blogpost we talked about the security issues with the IPv6 Header that can be manipulated for multiple attacks. While these attacks may occur from time to time "in the wild", what really is a concern with Header Manipulation is fragmentation of the IPv6 header/packet. This is used to bypass firewalls / IDS or RA Guard on a switch. As you can see, this poses even greater risks as the attacks explained in the previous post are either not a great threat in small numbers or ,assuming you frequently update/upgrade your systems, simply don't work anymore. I will explain ways you can achieve a bypass via fragmentation.

Method 1: Fragmentation

This part is the base of fragmentation bypasses. The way this is exploited is by how firewalls / IDS or RA Guard check an IPv6 packet. First of all for routers that have work as a firewall to (like in my test setups, pfSense acts both as a router and as a firewall) or just routers in general, as long as the "Hop-by-Hop" Next Header is not specified, routers will not perform "deep" inspection of the packets, this means they will only look at the information needed from the IPv6 Header to forward the packet (which is usually the first packet unless specified otherwise). Which of course makes it easy do "hide" malicious data in the other fragments (e.g. Spoofed RA).
With firewalls, they most commonly only look at the unfragmentable part of the packet and check that for any malicious intent. Another way is to spread the attack into multiple fragmented packets that seemingly look safe but when reassembeld by the destination host, make a malicious packet. As you can see in figure one, a firewall will most likely only look at the unfragmentable part, so if they put an attack in the second fragment (like a RA) this could go unnoticed

Figure 1: Fragmentation. [1]

 

 



Method 2: Large Destination Header Option

Another method to try and bypass a firewall / RA Guard is by spoofing a large Destination Header with more than 2kb of payload of useless data causing it to be split (fragmented). Usually Firewalls will then only check the remainder of the Destiantion Header Option payload in the next fragment and thus a packet like an RA could be added. Since this is a Destination Header Option, routers should not inspect this packet since it is only ment to be checked at the destination. An added "bonus" with this bypass is that due to the large payload of the Destination Header Option you could inadvertadly crash the firewall since it should not have to process such a large Option. This only happens with firewalls that have low resources / not alot of processing power or badly configured ones. In figure 2 it is shown how such a large destination header fragmentation works.

 

Figure 2: Large destination bypass [2]

 

 

 

Method 3: Hop-by-Hop Header Option

The third method is also somewhere along the lines of the second methode, only this time you do it with Hop-by-Hop Header option. You again craft a Hop-by-Hop option that is to large to be fit in one packet so that it is fragmented. In the second packet you then add an RA (for your attack) after the fragmented Hop-by-Hop option. Again, routers will only look at the second fragment for the Hop-by-Hop information and will not see the RA that follows the option. I refer back to figure 2 for this bypass, as the only thing that changes is the Dest. Opt. Header into the hop-by-hop Option Header.

 

Conclusion

As you can see there are a few ways you can try to bypass staple IPv6 network security machines like firewalls and RA Guard. The reason I discussed multiple of essentialy the same concept is that some firewalls protect agains some attacks or some routers protect against some attacks. E.g. If you test this bypass on your firewall but you let the fragments overlap, this will almost centainly be picked up by any modern / updated firewall whereas if you use the Large destination option header bypass instead, the attack might still work. In general alot of these bypasses can be caught if you use deep packet inspection but it is worth considering that of course this slows down traffic into your network significantly and a complex well constructed packet could still be passed through.

 

There are other ways you could try to spoof the packets into fragmentation with different payloads, different options etc. These are the most easily tested since they are included in the THC IPv6 Toolkit as option in various attacks.

References:
[1] Cisco: IPv6 Security by Eric Vyncke
[2] http://blog.si6networks.com/

https://tools.ietf.org/html/rfc6980
http://tools.ietf.org/search/rfc5722
http://www.si6networks.com/presentations/deepsec2011/fgont-deepsec2011-hacking-ipv6-networks.pdf
https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05
https://tools.ietf.org/html/rfc2460



IPv6 Header Manipulation

This blogpost will address some of the possible attacks that can be executed by manipulating the IPv6 Next Header Fields. A Next Header Field in an IPv6 packet specifies which protocol is encapsulated in the next header (hence the name) of an IPv6 packet. These are called extension headers This is possible because in IPv6 you can theoretically link infinite Headers to each other creating one packet that handels different kinds of protocols. Of course there are flaws in this system by manipulating specific fields in those headers. On a different note, this also causes the router to only inspect the first Header and ignore the rest on default (unless you specify it via the router alert field in the hop-by-hop header). This is a whole other problem on it's own and will be discussed in a later blog post to minimize the reading length of both blogposts.

IPv6 Packet

 For reference, this is how a normal IPv6 packet looks like

Figure 1 - IPv6 packet [1]

 

 

You can see the next Header field in which you can specify what the next extension header should be. This can be seen in an example packet of figure 2. Also note the chaining of those headers, in  practice no more than one or rarely 2 will ever be used in a normal packet. In theory though, you could chain them infinitly which cause security issues. There are a number of those header extensions possible although it is most widely used for TCP & UDP, you can also add fragmentation headers, Hop-by-hop headers, etc. Not all will be handeld in this scope, only those interesting for possible exploitations.

 



Figure 2 - IPv6 extension header [2]

 

 

Router Alert

 

The router alert option is an field inside the Hop-by-hop Header Extension Option. This option is actually a part of a security feature inside the IPv6 packet. If this option is enabled this alerts each router on the path do inspect this packet more closesly. If not abused this is actually a good way to perform some kind of packet inspection at each router. The problem is that IPv6 packets are designed to be passed by routers quickly but still carry larger amounts of data than IPv4 packets. So by default this option is rarely enabled an IPv6 traffic passes quickly throug the network since the packet isn't inspected any further. If this is enabled it take the router some resources to inspect it. Of course this is talking on such a small scale it does not really matter IF it is part of the normal traffic. We can easily send out thousands of these packets that have to be inspected by each router. Which could deplete the router of it's resources very quickly and cause delay, good packets being dropped or even a DoS of that part of the network.

 

This attack is actually very simple to replicate. With scapy we just craft an IPv6 packet with a NH field of 0 which specifies an Hop By Hop NH. In that Hop by Hop you just specify a router alert. This will make each router check that packet.

In Scapy

>>>a = "DESTINATION"

>>>pckt = IPv6(dst=a, nh=0)/IPv6ExtHdrOptHopByHop(options=[RouterAlert()])

>>>send(pckt * 10000) /* Note this will send 10 000 packets! */

 

This attack has little impact on most routers on it's own, but in case of routers which process alot of traffic already of that have very limited resources, this can be overwhelming. The addition of another Extension Header will take up even more resources.

 

RH0 Attack

NOTE: before testing this attack, note that IETF has depricated the use of the RH0 option because of it's security issues. This means that in normal traffic, this should not be encountered anymore and thus should always be blocked.

 

This option was intended to bounce traffic off of a midpoint note onwards to it's destination by including a intermediate addresses. This would bounce the traffic further and further forward if those addresses were known. Of course this is easily crafted into bouncing traffic between two nodes instead of trough a network. This can congest a nework with alot of useless traffic and make the nodes drop good traffic. Since it is so easily implemented and not really used if you have a decent network, it was decided to be deprecated. Of course this does not mean we cannot test this OR that everyone has updated against this attack.

 

We simply use scapy to craft a packet sent to our victim, and specify the Router Header option to be 0.

 

>>>atck="SOURCE"

>>>vict="DESTINATION"

>>>mid="MIDWAYADR"

>>>pckt=IPv6(src=atck,dst=vict)/IPv6ExtHdrRouting(addresses[mid])/ICMPv6EchoRequest()

 

You can add multiple addresses in the addresses option (up to 88!) which has greater impact since more packetw will be bounced off.

Router Lifetime 0

The last attack in this blogpost abuses the router lifetime field of a router advertisement packet. This should normally indicate a neighbouring node that somewhere along the path, a default router has gone down and should be deleted from their respective routing tables. This is simply done by setting the router lifetime field to 0. If this is the only default router this will result in a (temporary) DoS of the client as he will have no default router anymore. If an attacker is quick about it and sends an RS packet to that client he can be vieuwed as the new default router and be a MITM.

 

We can test this through 2 tools, THC Ipv6 toolkit of scapy if a more detailed view is desired.

 

In THC:

kill_router6 INT RTRADR /* INT specifies the interface of the attacker that is connected to the network and DSTADR is the address of the default router you wish to delete */

 

In Scapy:

>>>a = IPv6(dst=RADDR)
>>>b= ICMPv6ND_RA(routerlifetime=0)
>>>send(a/b)

 

Conclusion

There are many ways the options of an extension header can be manipulated into malicious packets. Some of these are already dealt with by IETF, but this should not mean that no measurements against them should be taken. If working with Cisco Routers it is advised to setup ACL's that block traffic with those specific options enabled from progressing through the network. In the next blog post we will examine the use of the same extension headers to bypass firewalls, IDS or RA Guard.

 

References:

[1] = IPv6 Security by Eric Vyncke

[2] = http://tclscripting.blogspot.co.uk/2012/11/ipv6-or-internet-protocol-next.html#!/2012/11/ipv6-or-internet-protocol-next.html

http://tools.ietf.org/html/rfc4861#page-19
http://www.ietf.org/rfc/rfc5095.txt
http://tools.ietf.org/html/rfc6398

 http://www.faqs.org/rfcs/rfc2711.html

 

 

 

 

 





SLAAC Testing revisited

A few weeks ago I made a post about the SLAAC Attack and how you could test this. This test was written before the actual testing began and was more of a theoretical research about possible ways to set it up than it was actually effecient to test. In this blogpost I will review the testing part of my last blog since there is a bit more to testing it "for real" then in theory.

Testing Topology

Since the SLAAC attack is a MITM kind of attack, the best way for us to test this is via a router connected to the internet (a pfSense router in our case) connected to a switch and with an attacker and in my case a Windows client and a Linux client to see if we have any differences.

Setup of hosts/attackers

The victim hosts and the router should only distribute IPv4 addresses but you cannot disable IPv6 traffic on either of them. This is because this attack assumes an unknowing (or poorly trained) IT admin who set up good IPv4 protecting but didn't disable nor add IPv6 security to his network. If we would disable IPv6 traffic, the purpose of this test would be defeated since it would no longer work.

Now the attacker is another story, first of all do not forget to enable ipv6 forwarding on the attacker. Since you are spoofing yourself as a router, failing to enable this will cause the attacker to be flooded with traffic but having no way to forward it, this will result in a DoS of your own system. Second for ease of the preparation even if only for the installation, connect to the internet. The tool we will be using downloads/installs and configures multiple packages at once to make the testing easier. If ,like me, you do not have an internet connection (e.g. working through a VM on a company network) you will have to download all those packages manually (and their dependencies) and install them. Since the script still configures them for you that is handled, but many things can go wrong with manually installing all the packages and is not recommended (when I did receive an account capable of receiving internet through my VM I just restarted from my last snapshot and let the script install them, no problems then!).

The script is called SuddenSix by Neophasis labs. It is free for download at their github (google it). It is easy to use (no ./configure, make, make install needed) by just going to the directory where the script is stored and typing:

./suddensix.sh

That is all! Now it will begin installing (if it is your first time using it) all the needed packages, these are: WIDE DHCP server, bind9, radvd, sipcalc, tayga and their dependencies. After that you only need to give the interface from which you send the attack and a free ipv4 address in the victim network. Here a screenshot of the commands you should see

After this, the script will set everything up, configure it right and give the hosts connected to the network an IPv6 address. This is a debian client and a vista client before the attack.

And after the attack is started:

As you can clearly see, both the vista and the debian client received an IPv6 address, whats more you can also see the see that the standard gateway is set to the Link Local Address of our attacker host. Now we know the victims are in "our" IPv6 network. If you are connected to the internet you can see the MITM attack in action.

Here I will show you some examples of capturing a TCP stream over our IPv6 network, visiting IPv4 websites. (and their login info).

First of all, a login to an unsecure page (just Http, no https) via our vista client

Then on the attacker, you can capture the traffic routed throug our interface (note when a website is queried by the victim, it is sent from it's ipv6 addres, in this case 2001:db8:1:0::/64, it is then routed through the IPv4 internet to reach the site

And the sniff of my attempt to login, you can see my username and password with which I tried to login.

You can clearely see my login credentials sniffed from our victim host. Immediatly showing it's danger since this was just a normal IPv4 network that has been breached by IPv6.

Conclusion

A powerfull attack that when launced can get devastating results if not proteced correctly against. Of course the drawback of this attack is that you have to be inside the vicims local network to pull this off. But still, with so many public places giving out free WiFi, if unprotected against IPv6, this attack could listen to the traffic from an entire restaurant, etc.

References:

http://resources.infosecinstitute.com/slaac-attack-/

http://tools.ietf.org/html/rfc4966

http://www.informationweek.com/security/vulnerabilities-and-threats/windows-ipv4-networks-vulnerable-to-ipv6-attack/d/d-id/1097153?

http://labs.neohapsis.com/2013/07/30/picking-up-the-slaac-with-sudden-six/

Test Network Topologies

In deze blogpost zal ik mijn voorlopige testopstellingen bespreken en waarom deze gekozen te hebben. Ik begin met het uitlichten van mijn originele testopstelling en waarom deze verkleind is. Dan zal ik ieder van mijn testopstellingen die ik voorlopig denk te hanteren uitlichten.


Bij het testen van een IPv6 netwerk gaat het niet alleen maar over het onderzoeken en het uitschrijven van iedere aanval. Je moet praktische ervaring verwerven en voor jezelf documenteren welke aanvallen standaard op welke OS werken. Mijn originele idee was 1 netwerk te draaien waar ik iedere aanval die ik beschreven had zou kunnen testen. Dit leek mij makkelijker aangezien er ,buiten het verplaatsen van de aanvaller, weinig extra configuratie tussen de tests door zou zijn. Hier een voorbeeld van mijn eerste testopstelling

Originele testuitvoering

Hierbij zou het linker deel het IPv6 "only" gedeelte zijn waar ik de tests uit zou voeren die enkel op IPv6 werken. Het rechtse gedeelte zou dan mijn testopstelling zijn voor de IPv4 SLAAC attack en de ISATAP Tunnel. De hosts aan beide gedeelte zouden een Windows client en een Linux client zijn en ik zou dezelfde test meerdere keren herhalen met dan andere versies om te kijken waar dit verschilt in resultaat. De server was toegevoegd puur voor de DNS Dictionairy attack.

Het grootste nadeel van deze opstelling was dat het wel heel erg veel resources zou kosten om dit allemaal virtueel op 1 computer te draaien (fysiek was ook niet mogelijk inzake van geluid in het kantoor, het aantal computers/switches/routers benodigd) en dit dan ook niet zou werken op 1 computer. Er zou dus zoiezo al naar meerder computers moeten worden afgescheiden en dus zouden de netwerken ook opgedeeld worden. Daarom leek het beter om testopstellingen voor de verschillende tests op te zetten.

Testopstelling 1: Alles IPv6

 Voor al onze testen van IPv6 zelf hebben we niet meer nodig dan deze simpele opstelling. Zoals de figuur zegt, alleen 2 clients van 2 verschillende OS om te testen welke al dan niet door een aanval wordt beinvloed. En een router die de default router is van die specifiek netwerk. Vanuit dit simpel netwerk kan er ondermeer getest worden op scanning, sniffing, spoofing, MITM, DoS, ICMPv6 exploits, packet manipulation. Voor al deze aanvallen moet de aanvaller enkel op het netwerk worden aangesloten. Dit vraag al een stuk minder resources van de computer (3 clients en mogelijk 1 client met een pfSens om een router na te bootsen). Deze clients zelf hebben niet veel resources nodig (qua ram niet meer dan 512mb ieder) aangezien ze gewoon idle staan.

Testopstelling 2: MIPv6

 

 Deze testopstelling is wederom zeer simpel. Deze testopstelling is maar bedoeld voor 1 type aanval op te testen, namelijk een Session hijack. Dit kan zelfs makkelijk met basis toestellen getest worden die iedereen thuis heeft staan (de router die het internet verdeeld, een smartphone of laptop en een 2de laptop die de aanvaller voorstelt). Hier wordt niet gekeken naar de opvolging van de session hijack (MITM of DoS van het slachtoffer) aangezien deze worden behandeld in de vorige testopstelling.

Testopstelling 3: IPv4 SLAAC Attack

Deze opstelling is volledig hetzelfde als de eerste opstelling, alleen is deze keer alles IPv4 ipv IPv6. Het enige verschil is de simulatie van een IPv4 netwerk door een cloud figuur. Dit is enkel toegevoegd om onderscheid tussen de 2 testopstellingen te maken aangezien in realiteit dit gesimuleerd zal worden met een Loopback op de default router.

Testopstelling 4: Tunnels

De laatste testopstelling hebben we geen clients nodig afgezien van onze aanvaller (en als de routers worden gesimuleerd door een client met pfSense bv.) De IPv6 netwerken aan beide IPv6-IPv4 routers zijn loopback interfaces ingesteld met een IPv6 address om IPv6 netwerken te simuleren. De tunnel is een ISATAP tunnel die IPv6 verkeer toelaat over het IPv4 netwerk.

Conclusie

Zoals in het begin aangehaald is de eerste testopstelling niet haalbaar door het aantal resources dit zou innemen zowel op de computer zelf als fysiek in het aantal toestellen dat nodig zou zijn. Indien nodig kunnen al deze aparte testopstellingen nog worden samengevoegd tot 1 groot netwerk mocht men beschikken over voldoende toestellen en resources.

Enkele opmerkingen: Zoals je ziet is er nergens een DNS server te bespeuren bij onze opgedeelde opstellingen. Dit is gewoon omdat de DNS Dictionairy attack niets anders is al een nslookup van een server. Dit kan je zelfs manueel (dan wel 1 per 1) uitvoeren in de CLI op je eigen computer. Het programma kijkt gewoon op veel voorkomende namen voor subdomeinen en leid hier het IPv6 adres af. Aangezien dit makkelijk te testen valt met een gewone computer is dit niet opgenomen in de tests
Tevens zijn alle netwerken gesimuleerd in cisco Packet Tracer waar deze ook al geconfigureerd zijn om de standaard opstelling later zo vlot mogelijk te laten verlopen.

Transitional Threats: SLAAC Attack

In deze blogpost zal ik de werking van een SLAAC aanval uitleggen en deze later testen op een intern netwerk. Een echte SLAAC aanval bestaat uit nog meer componenten (DHCP, DNS) maar deze worden hier niet in behandeld omdat we een intern netwerk testen om te kijken of deze aanval gewoon al lukt.


In de overgang van IPv4 naar IPv6 zijn er verschillende mogelijkheden om connectie over beiden te behouden. 1 daarvan is de dualstack methode. Dit wil gewoon zeggen dat mijn naast IPv4 ook IPv6 draait en verkeer langs beiden kan hebben. Nu vele OS of machines hebben IPv6 automatisch geenabled en hebben voor IPv6 ook nog eens een voorkeur zodat als men beiden zou draaien vaak traffic langs IPv6 herleid worden.

Nu wat heeft dit met deze aanval te maken? Het probleem is dat velen een volledig werkend IPv4 netwerk draaiende hebben en niet beseffen dat IPv6 standaard werkt. Ook al heb je niets geconfigureerd, de hosts zijn IPv6 "aware" en zullen dus bij eerste Router Advertisement (van een rogue router misschien) hunzelf automatisch configureren (SLAAC). Je kan dan denken, ok dan wordt alle traffic van IPv6 langs daar geroute, maar als dit een volledig werkend (en beveiligd) IPv4 netwerk hebben en er zijn maar heel weinig applicaties puur op IPv6 draaien. Je kan nu natuurlijk andere aanvallen op het netwerk afsturen, maar dit is niet de bedoeling van deze aanval.

Bij deze aanval is het de bedoeling dat je alle IPv4 (& dus ook IPv6) traffic langs je router stuurt, die verbonden is met de rest van hun IPv4 netwerk (of internet). Wat je nog extra nodig hebt is een manier om alle IPv4 netwerk ook nog eens te laten redirecten. De beste manier voor dit is het NAT-PT mechanisme te gebruiken. Dit is een mechanisme om de overgans normaliter makkelijker te maken. Maar dit heeft zoveel security threats dat IETF heeft besloten dit mechanisme als deprecated te beschouwen en wordt niet meer ondersteunt. Dit wil niet zeggen dat wij het niet meer kunnen gebruiken! Het grote voordeel voor ons is dat dit mechanisme automatisch werkt zonder interactie van het slachtoffer. Het zorgt ervoor dat IPv6 hosts naar IPv4 hosts kunnen connectie maken door IPv6 adressen te vertalen in IPv4 adressen. Je ziet dat zo onze IPv6 verbonden hosts hun verkeer langs ons gaan "vertalen" als het ware om te connecteren naar het IPv4 netwerk.

Voor NAT-PT te configureren op een router moet je eerst nat mogelijke maken op de specifieke interface. Vervolgens een pool aanmaken met IPv4 adressen waaruit de vertaling kan bestaan en als laatste een /96 prefix definieren (deze moet overeen komen met de /64 prefix die je gaat uitzenden voor je RA packet om IPv6 te autoconfigureren, zie voorbeeld). Dan zal een adres bestaan uit de /96 gedefineerde prefix en de laatste bits zullen dan bestaan uit het IPv4 adres dat de host hebben toegewezen gekregen.

Als je je router goed geconfigureerd hebt rest ons nog alleen een RA packet te forgen om zo de autoconfiguratie op gang te zetten. Dit kan makkelijk gedaan worden in scapy. Het enige waar specifiek op gelet moet worden is dat de /64 prefix die gedefineerd moet worden hezelfde is al de eerste 64 bits van de gekozen /96 prefix bij de configuratie van NAT-PT.

Even een voorbeeld:
-RA in scapy:


./scapy.py
>>>a = IPv6(dst=LLA)
>>>b= ICMPv6ND_RA()
>>>c = ICMPv6NDOptSrcLLAddr(lladr=SLLA)
>>>d = ICMPv6NDOptMTU()
>>>e = ICMPv6NDOptPrefixInfo(prefixlen = PREFL, prefix = “PREF”)
>>>display(a/b/c/d/e) /* Optional used to check if packet is correctly forged */
>>>send(a/b/c/d/e)



Het paket is onderverdeeld in de verschillende stukken om een beter overzicht te krijgen (je kunt dit natuurlijk omschrijven in een one-liner). Het eerste is een IPv6 pakket met een LLA, het LLA voor deze aanval is een LL Multicast adres om dit naar alle hosts in het IPv4 netwerk te versturen. Dan de aanmaak van een RA packet (b). Vervolgens worden de opties gedefinieerd (c, d). In c wordt het source LLA gedefineerd, dit is ons eigen MAC adres zodat alle traffic langs ons passeert. in e configureer je dan de prefix die de IPv6 adressen van de hosts moeten hebben. Zoals eerder gezegd is dit een /64 adres dat moet overeen komen met de eerste 64 bits van het gekozen /96 adres.

-NAT-PT op je rogue router

/* enables NAT-PT on that interface */
interface ETHPORT
    ipv6 nat

/*Sets Dynamic nat for IPv6 to IPv4 */
ipv6 nat v6v4 source list NAT_TRAFFIC pool IPV6_TO_IPV4

/* Specifies the dynamic NAT IPv4 pool */
ipv6 nat v6v4 pool IPV6_TO_IPV4 4ADRRANGEBEGIN 4ADRRANGEEND prefix-length 24

/*Specify the IPv6 NAT prefix */
ipv6 nat prefix PREFNAT

/* ACL to specify traffic eligible for NAT-PT */
ipv6 access-list NAT_TRAFFIC

     permit ipv6 any PREFNAT

Zoals je kunt zien is dit geconfigureerd op een cisco systeem. Je kan dit ook op een host configureren zodat je geen 2 devices moet configureren. In dit geval verwijs ik naar de onderstaande link van infosecInstitute men de opvolging van deze aanval uitgebreid uitlegt. Aangezien dit voor studiegerichte doeleinden wordt gebruikt, heb ik gekozen voor een simpele configuratie in een cisco systeem.

Je mag de begin en eind adressen  voor de IPv4 pool zelf kiezen. Het enige waar op gelet moet worden is de /96 prefix.

Met deze laatste configuratie kan je de host aansluiten en je zal zien bij het versturen van de RA packet dat de victim hosts een IPv6 adres bezitten dat zijn verkeer via ons herleid. En je hebt een succesvolle MITM aanval van een IPv4 netwerk met een IPv6 overlay!

NOOT: Deze aanval is in het kader van mijn stage opgemaakt voor test redenen. Zoals Dhr. Alec Waters configureert (zie link van infosecinsitute) is veel complexer en uitgebreider met nog DHCPv6 spoofing om effectief met het internet verbonden te kunnen worden en het gebruik van een DNS server. Ik kon natuurlijk gewoon volledig Dhr. Waters zijn aanval overnemen, maar mij leek het interessanter om zelf een vorm van deze aanval uit te voeren die past in het kader van de andere tests. Tevens heeft een een groep researchers van Neophasis labs een tool gecreëerd genaamd Sudden Six om al deze complexe configuratie van Dhr. Waters in enkele minuten te laten overlopen. Nogmaals, hiervoor is niet gekozen omdat ik zelf een beter inzicht in deze aanval wou hebben.

CONCLUSIE:

Deze aanval maakt het mogelijk om zodra je een rogue device in een IPv4 netwerk kan plaatsen een makkelijke overlay te plaatsen van een IPv6 netwerk. Deze aanval is niet zo complex uit te voeren en is vooral destructief voor goed beveiligde IPv4 netwerken die nog niets aan hun IPv6 beveiliging gedaan hebben.

Referenties:
Info over de SLAAC aanval zelf:
- http://resources.infosecinstitute.com/slaac-attack-/
- http://www.informationweek.com/security/vulnerabilities-and-threats/windows-ipv4-networks-vulnerable-to-ipv6-attack/d/d-id/1097153?
- Cisco Press: IPv6 Security by Eric Vyncke (Hoofdstuk over Transitional Threats

RFC:
- http://tools.ietf.org/html/rfc4966

RA packet:
- http://samsclass.info/ipv6/proj/projL3-scapy-ra.html
- http://isc.sans.edu/diary/IPv6+MITM+via+fake+router+advertisements/10660

NAT-PT:
- http://blog.ine.com/2008/04/18/understanding-ipv6-nat-pt/