donderdag 20 maart 2014

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
 
 
 
 
 


Gepost door op

Geen opmerkingen:

Een reactie posten

Abonneren op: Reacties posten (Atom)