Yet another web site regarding IT security from an IT security enthusiast.
I created this web site to share my thoughts, my work and my tools with you.
Your comments and questions are more than welcome.
Using Chiron you can define a list of the IPv6 Extension Headers that comprise the IPv6 header chain. To do so, you can use the following Chiron switches:
-lfE <comma_separated_list_of_headers_to_be_fragmented> Define an arbitrary list of Extension Headers which will be included in the fragmentable part.
-luE <comma_separated_list_of_headers_that_remain_unfragmented> Define an arbitrary list of Extension Headers which will be included in the unfragmentable part.
Note: In this section we will create an unfragmented IPv6 header chain only. Later, we shall also demonstrate how fragmentation is performed in IPv6 and how to create fragmented IPv6 header chains using Chiron.
The supported by Chiron IPv6 Extension Headers are the following:
IPv6 Extension Header
Fragment Extension Header
Destination Options Header
Any other value
IPv6 Fake (non-existing) Header
To add an IPv6 Extension header, you just need to use the corresponding header value, as shown in the examples below.
For instance, if you want to add a Destination Options header to perform ping scan (-sn), you can use the following Chiron command:
./chiron_scanner.py eth0 -d 2001:db8:1:1:e633:1ba7:95d0:c943 -sn -luE 60
In the above command:
eth0 is the network interface to be used by Chiron
-d <ipv6 address> is the IPv6 address of the target.
-sn is the network scan to be performed (ping scan)
Similarly, to add a Hop-by-Hop Header and a Destination Options header during a ping scan (-sn), you can use the following Chiron command:
./chiron_scanner.py eth0 -d 2001:db8:1:1:e633:1ba7:95d0:c943 -sn -luE 0,60
To add a Hop-by-Hop and three Destination Options header in a row during a ping scan (-sn), you can just “multiply” the header value with the number of times that you want to include this header in a row in the chain, as follows (please use a capital ‘X’):
./chiron_scanner.py eth0 -d 2001:db8:1:1:e633:1ba7:95d0:c943 -sn -luE 0,3X60
As simple as that.
The packet generated by the above command is depicted in the wireshark screenshot below:
As we can see, we have sent a simple ping request by adding in the IPv6 chain a Hop-by-Hop Extension header and three (3) Destination Option headers.
In the above example, the length of the Destination Option headers is 1 octet of bytes.
However, the length of the Options Headers (Hop-by-Hop and Destination Options), due to their TLV format, can vary arbitrarily. To create lengthy IPv6 Options headers using Chiron (this will become useful later when fragmentation will join the game), you can use the following switch:
-seh <SIZE_OF_EXTHEADERS> the size of the Options Extension header in octets of bytes (default value: 1 octet of byte).
./chiron_scanner.py eth0 -d fd9e:488f:c9e9:b6fd:a00:27ff:fe10:8fc -sn -luE 60 -seh 3
In the above example, the Destination Options Header is included in the IPv6 chain and its size is 3 octets of bytes (this applies to all Option headers used in the command, i.e. both Hop-by-hop and Destination Options). The packet is depicted in the wireshark output below:
I guess that you can easily spot the difference.
In the next blog post we will start discussing fragmentation in IPv6.
This is the first of a series of blog posts aiming at describing how to use Chiron to abuse IPv6, and especially IPv6 Extension Headers. However, in order to understand the possibilities that exist with regard to the abuse of IPv6 Extension Headers, we first need to understand the related standardisation foundation.
My objective is that when this series of the blog posts come to an end, the reader shall be able not only to reproduce all the known related attacks, but also to compile and implement his own attack methods. And this is exactly the power of Chiron: it does not just implement known attacks (there are other tools that do it really well), but it provides you the ability and flexibility to implement any kind of related attack, new or not, without having to write a single line of code.
IPv6, initially introduced with [RFC 1883] and [RFC 2460], and lately updated with [RFC 8200], brings several important changes to the IP protocol. Among them, as stated in these RFCs, is the “Improved Support for Extensions and Options”. Specifically, it is described that “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future”.
Whilst “greater flexibility” and “less stringent forwarding” are usually welcome from operational and interoperability perspective, typically they also introduce security implications. As several publications at security conferences or even RFCs has shown (see for example [RFC 7112]), IPv6 Extension Headers unfortunately is not an exception. These security implications become even more important when combined with fragmentation (but I will talk about them in another article).
In this article I will first refresh our memory by summarising the IPv6 Extension Headers concept. Despite my objective is not to discuss extensively and analyse the security implications themselves that arise from the support of IPv6 Extension Headers, I will summarise them briefly and I will point to the right publications.
In IPv6, the IPv6 header (from now on called IPv6 main header) has been simplified in comparison with IPv4 header, whilst its size is constant to 40 bytes (and cannot not vary, is it is the case of IPv4). However, IPv6 Extension headers have been introduced to allow the incorporation and usage of several options, only if and when needed. These IPv6 Extension headers, which can be none, one, or more, follow the IPv6 main header and come before the layer 4 header (e.g. TCP, or UDP) and its payload.
The IPv6 Extension headers are identified by their protocol number, which is used by the preceding header in the so called “Next header” (Nh) field to “point” to (i.e. to indicate) the next header. The protocol numbers of the IPv6 Extension headers are included in the IANA “Assigned Internet Protocol Numbers” list.
A few examples of how IPv6 header chains are constructed are given in the figure of Chapter 4 of [RFC 8200] and depicted below:
The case where IPv6 fragmentation is involved will be examined in a next article.
Each extension header is an integer multiple of 8 octets long, to retain 8-octet alignment for subsequent headers. A uniform format for IPv6 Extension Headers is defined in [RFC 6564]. Currently, all but the Fragment Extension header (which was defined earlier than [RFC 6564]) follow this uniform format, which is depicted below:
The “Next Header” filed identifies the type of header immediately following this extension header, while “Hdr Ext Len” filed provides the length of the extension header in 8-octet units, not including the first 8 octets.
A list of the currently defined IPv6 Extension headers, as summarised in [RFC 7045], along with the corresponding protocol numbers, is given below:
IPv6 Hop-by-Hop Option, protocol number 0, currently defined in [RFC 8200].
Routing Header for IPv6, protocol number 43, currently defined in [RFC 8200] (the currently defined types of routing headers can be found at “Internet Protocol Version 6 (IPv6) Parameters – Routing Types”).
Fragment Header for IPv6, protocol number 44, currently defined in [RFC 8200].
Encapsulating Security Payload, protocol number 50, currently defined in [RFC 4303].
Authentication Header, protocol number 51, currently defined in [RFC 4302].
Destination Options for IPv6, protocol number 60, [RFC 8200].
Mobility Header, protocol number 135, currently defined in [RFC 6275].
Host Identity Protocol Version 2, protocol number 139, currently defined in [RFC 7401].
Shim6 Protocol, protocol number 140, defined in [RFC 5533].
This list excludes the next header type 59, called “No Next Header”, defined in [RFC 8200], which is not an extension header as such.
It should be noted that if the upper-layer header is another IPv6 header (in the case of IPv6 being tunnelled over or encapsulated in IPv6), it may be followed by its own extension headers (which are separately subject to the same ordering recommendations – see below).
The recommended IPv6 Extension header order is defined in [RFC 8200]. In a nutshell, “each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header)”. However, as it is also clearly stated in [RFC 8200], “IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only”.
It should also be noted that, as described in [RFC 8200], “Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches” its final destination (whilst “the Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path”, if a node is “explicitly configured to do so”).
At the destination node, extension headers must be processed strictly in the order they appear in the packet; the contents and semantics of each extension header determine whether or not to proceed to the next header.
If the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet (more details can be found in [RFC 8200]). The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header.
Further information regarding the transmission and processing of IPv6 Extension Headers can be found in [RFC 7045]...
As explained above, the introduction of Extension Headers into IPv6 introduces enormous flexibility in terms of the options that are or can be supported in the future. In a nutshell, their types, the formats of some of them and the rules of construction of the IPv6 header chain render the potential possibilities and combinations almost infinite.
The situation from a security perspective becomes even more complicated when considering that the rules governing the processing of the Extension Headers at recipient’s side follow closely the robustness principle (i.e. "be conservative in what you send, be liberal in what you accept from others").
Whilst it is not in the scope of this article to discuss and analyse the various security implications related with the abuse of IPv6 Extension Headers, these can mainly be summarised to the break of any type of signatures (e.g. Access Control Lists, IDS signatures) or similar control mechanisms in several security mechanisms (e.g. routers, IDS, or even firewalls).
For more, detailed information, the reader can refer to the following: