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