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.