This is a guest post from Antonios Atlasis.
Last week I had the pleasure to give you my impressions regarding my experience about hacking for b33r at Ghent, that is, my participation at BruCON 2014 hacking conference. As I said among else, the reason that I was there was to present Chiron, my IPv6 penetration testing/security assessment framework, which was supported by the Brucon 5×5 program. The first version of Chiron had been presented at Troopers 14, during the IPv6 Security Summit.
But what exactly is Chiron and what are the differences, if any, from other well-known IPv6 penetration testing frameworks? I will try to give you an idea quite briefly. For motivation purposes, just allow me to say before starting to describe it, that it is this tool we used to find evasion vulnerabilities at popular IDPS appliances, like Tipping Point and Suricata, to run the RISC project, to prepare our BlackHat US 2014 and the upcoming BlackHat EU 2014 presentations, etc.
But, let’s start. Chiron is a multi-threaded tool written in Python and based on Scapy. It can run on Linux systems and it is comprised of the following modules:
- IPv6 Scanner
- IPv6 Link Local Messages Creation Tool
- IPv4-to-IPv6 Proxy
All the above modules are supported by a common library that allows the creation of completely arbitrary IPv6 header chains, fragmented or not.
Chiron must be run with root privileges, it provides just a CLI (sorry GUI fans…), but it is accompanied by a detailed – with examples – documentation. A good knowledge of the corresponding IPv6 RFCs is a plus if you want to use its advanced features.
One significant difference in comparison with other IPv6 pen-testing tools is that it does not implement out-of-the-box some well-known attacks, such as the SLAAC attack, Router DoS or redirections attacks, etc., but it allows you to do so by constructing and sending – very easily – the required packets to achieve these attacks on your own. But the main focus of Chiron is on the construction of arbitrary header chains. This capability can be used:
- To test the IPv6 protocol design.
- To test the IPv6 protocol implementation.
- To evade IDS/IPS devices, firewalls, or other security or networking devices.
- To fuzz IPv6-capable devices regarding the handling of IPv6 extension headers and their parameters.
But, let’s start.
The Chiron Scanner module incorporates most of the usual scanning techniques known from other tools like nmap plus some IPv6-specific (e.g. IPv6 multicast ping, etc.). You can use as destinations:
- list of IPv6 addresses.
- IPv6 subnets (just be careful, if you want to finish before the end of the life of the universe…).
- IPv6 ranges like 2001:db8::1-ffff
- “Smart” scan combinations (by combining suffixes like ‘face’, ‘b00c’, ‘beef’, etc).
Please “Read The Fine Manual” (RTFM) for more info and more capabilities (source spoofing, defining MAC addresses, etc.).
The Chiron Link-Local module supports the following messages:
- Router Advertisement Messages
- Router Solicitation Messages
- Neighbor Advertisement Messages
- Neighbor Solicitation Messages
- Router Redirect
- Packet Too Big
- MLD/MLDv2 Messages (Queries, Reports, Done)
You can define on them every single parameter. Doing so, you can launch several attacks, like the ones mentioned above. Again, the accompanied documentation is your friend.
The other module is the IPv4-to-IPv6 Proxy. The purpose of this tool is the following. Many of our favourite penetration testing tools do not support, at least not yet, IPv6 and hence, we cannot use them against IPv6 “targets”. However, even if they do so, they are used exactly in the same way as it was used to be in IPv4. That is, they do not “exploit” all the features and the capabilities of the IPv6 protocols, such as the IPv6 Extension Headers.
This module of the framework operates like a proxy between the IPv4 and the IPv6 protocol. It is not a common proxy like web proxy, because it operates at layer 3. It accepts packets at a specific IPv4 address, extracts the layer-4 header and its payload, and sends them to a “target” using IPv6 but adding optionally one or more IPv6 extension headers.
So, if you find a way to evade a security device, then you can use this module to apply the discovered technique in combination with other penetration testing tool. During the presentation of Chiron at Brucon, I gave a live demo where I launched Nikto (which does not support IPv6 at all) against a target without triggering any alert at an underlying well-known IDPS.
As far as the advanced features of Chiron are concerned, in a nutshell the following techniques are currently supported:
- (Simple) fragmentation
- Flooding
- Crafting arbitrary IPv6 Extension Headers, regarding:
- Type of extension headers
- Number of occurrences of specific types of extension headers
- Order of extension headers
- Arbitrary extension headers parameters
- Arbitrary next header values
- Advanced fragmentation (e.g. fragmentation overlapping)
- Fuzzing of IPv6 extension headers’ parameters.
All the above techniques can be combined with the Scanner, the Proxy or the Local Link modules.
As you can imagine, it is not that easy to explain every single feature of Chiron, but I will try to give you some representative examples nevertheless.
Constructing Complex IPv6 Datagrams
Let’s send a simple IPv6 Echo Request (-sn) by preceding an IPv6 extension headers chain, comprised of:
– One (1) Hop-by-Hop header (protocol value: 0)
– Three (3) Destination Options headers (protocol value: 60, that is 3×60)
– One (1) Fragment Extension header (protocol value: 44)
– Another one (1) Destination Options header (protocol value: 60)
The Chiron command to do it is the following
./chiron_scanner.py eth0 -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -sn -luE 0,3×60,44,60
where:
– eth0 is the interface to use
–sn is used for ping-scan (just like nmap)
Now, let’s make something similar, but now we are going to split the IPv6 datagrams in two fragments, where:
– the unfragmentable part consists of a Hop-by-Hop header and three Destination Options headers.
– the fragmentable part consists of two (more) Destination Options headers.
The associated Chiron command is the following:
./chiron_scanner.py eth0 -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -sn -luE 0,3×60 -lfE 2×60 -nf 2
where:
-nf 2 defines the number of fragments to use.
-luE defines the list of the IPv6 extension headers to be used for the unfragmentable part of the chain.
-lfE defines the list of the IPv6 extension headers to be used for the fragmentable part of the chain.
But, what about if we want to define some parameters to some of the IPv6 extension headers? Pretty simple. Let’s see an example for an IPv6 Destination Options header:
./chiron_scanner.py eth0 -sn -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -lfE 60′(otype1=2;otype2=2;odata1=”AAAAAAAA”;odata2=”BBBBBBBB”)’
otype and odata should be self explanatory if you have a look at RFC 2460 regarding the Options of IPv6 Destination Options header. And another example, for an IPv6 Routing header this time.
./chiron_scanner.py eth0 -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -sn -luE 43″(type=0;addresses=fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa-fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa;segleft=2)”
What about sending various MLDv2 Report messages enclosing different Multicast Address Records but using just one command? Ranges are our friend here. Please try it by launching your favourite sniffer to get a clear idea about the effect of the command below:
./chiron_local_link.py eth0 -mldv2rm -ralert -no_of_mult_addr_recs 3 -lmar ‘(rtype=1;dst=ff15::25-30;no_of_sources=1;saddresses=ff02::4)’,'(rtype=2;dst=ff16::35-36;no_of_sources=2;saddresses=ff02::2-ff02::5)’,'(rtype=3;dst=ff17::45-46;no_of_sources=3;saddresses=ff02::1-ff02::2-ff02::5)’
Time for arbitrary fragmentation
OK, time for fragmentation (overlapping). Let’s try this:
./chiron_scanner.py eth0 -sn -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -lfE 60 -l4_data “AAAAAAAA” -nf 3 -lnh 60,60,60 -lm 1,1,0 -lo 0,1,1 -ll 1,1,2
Using the above command:
– You ask for three fragments (-nf 3).
– Each one of them has an offset equals to 0, 1, and 1 respectively (-lo 0,1,1) – defined in octets of bytes, as described in RFC 2460.
– The corresponding fragment lengths are 1, 1, and 2 (-ll 1,1,2) – again in octets of bytes.
– Their fragment (M) bit are 1, 1 and 0 (-lm 1,1,0)
– And last, but not least, the Next Header values of the corresponding Fragment extension headers are 60, 60 and 60 (-lnh 60,60,60).
By observing the above command we can conclude that the 2nd and 3rd fragment overlap (because they have the same offset). How can we make it non-overlapping (= “fully legitimate”)?
./chiron_scanner.py eth0 -sn -d fdf3:f0c0:2567:7fe4:a00:27ff:fe74:ddaa -lfE 60 -l4_data “AAAAAAAA” -nf 3 -lnh 60,60,60 -lm 1,1,0 -lo 0,1,2 -ll 1,1,2
Pretty simple, right?
If you liked it, you can download Chiron from here. Comments, requests, questions are more than welcome.
Do you want more? You have two options. As I said, you can read the documentation that accompanies Chiron or, you can simply join us at the IPv6 Training that we are giving together with Enno at DeepSec. In this training we will have the chance to cover Chiron, but also, much more IPv6-related attacks and defences 🙂
Have a nice weekend.
Antonios