Introduction
As a guy coming from network engineering, it is really exciting to see IPv6 adoption finally starting to pick up. According to Akamai, Belgium is leading the charge at a whopping 50.3% adoption rate, but the US is picking up steam at a respectable 24.3% at the end of 2016. This means the pentesting community will be seeing it more in our day to day work, which will come as something of a surprise to many.
IPv6 brings a lot of changes, many of which are relevant from a security perspective. It also brings with it unique potential for added vulnerable space that can be leveraged in network compromises. IPv6 is not well understood and prone to misconfiguration. During security assessments, I've seen these settings result in critical security vulnerabilities including a firewall configured to provide carte blanche access to the entire network for all traffic using IPv6. Operating in IPv6 and taking advantage of these weaknesses is a key opportunity for pentesters.
Methods Covered in this Section
- socat IPv4IPv6 Tunnel:
socat TCP4-LISTEN:80,fork,su=nobody TCP6:[2000::1:215:5dff:fe01:247]:80
- socat Local Link IPv4IPv6 Tunnel:
socat TCP4-LISTEN:445,fork,su=nobody TCP6:[fe80::2d24:c19c:892:4d3%eth0]:445
Background
There are a couple of things to understand before hopping into an IPv6-centric pentest. Most in the field are familiar with the big difference: a larger address space. The addresses are 128 bits instead of the traditional 32. If you are in a pentesting engagement, most of the targets you will encounter are broken into /64 subnets. ARIN, the agency responsible for IP address assignment in North America, is handing out the addresses in pretty generous chunks for now. This is probably a safe practice considering there are 3.402×10^38 possible addresses available.
Fun fact: there are roughly 7×10^27 atoms in the average 155 pound person. This means there are enough IPv6 addresses to assign an address to each atom of every person on the entire planet and have plenty of addresses left over.
One of the most notable differences in IPv6 is that interfaces can and frequently have multiple IP addresses. Each interface will *typically* have both a link local IP address and a global IP address.
eth0 Link encap:Ethernet HWaddr 00:15:5d:01:02:29
inet6 addr: 2000::1:215:5dff:fe01:229/64 Scope:Global
inet6 addr: fe80::215:5dff:fe01:229/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:118 errors:0 dropped:0 overruns:0 frame:0
TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18041 (18.0 KB) TX bytes:17748 (17.7 KB)
Above is a very common IPv6 configuration. Any global address will begin with "2000::/3" and a link local address will begin with "FE80::/10". On Linux distributions, this is annotated by Scope:Global or Scope:Link next to the address in the ifconfig command output. In IPv6, global IP addresses can be thought of in a similar fashion as public IP addresses in IPv4. However, unlike the IPv4 169.254.0.0/16 link local address space, almost all IPv6 interfaces will have an autoconfigured link local address typically generated from the interface's MAC address.
Pivoting with IPv6
Now that we have some background, we can examine pivoting techniques. Many tools natively support IPv6, but some do not. Consider, the web server vulnerability scanner Nikto:
Hmmm, not the results we were looking for. The problem is that Nikto doesn't understand IPv6! To get around this limitation we can use a technique called tunneling. The concept behind tunneling is encapsulation. In the case of Nikto, we need to encapsulate it's IPv4 content within an IPv6 stream. This condition often proves true in environments as well. Often IPv6 isn't ubiquitous throughout the network. In the network engineering community network pockets that support IPv6 are called IPv6 "islands." One way we link them together is by tunneling IPv6 over IPv4. IPv6 goes in, becomes IPv4, it traverses the IPv4 backbone, and comes out the other side IPv6. What this means to us as pentesters is that IPv6, in addition to having unique vulnerabilities, can frequently be a means to navigate from one part of a network to another. In some cases, an IPv6 target can take us behind the firewall and into the heart of the network. To get Nikto working against an IPv6 target we need to replicate this IPv4IPv6 condition on our local system.
To accomplish this we will use a tool called SOcket CAT or socat. SOCAT is a multipurpose relay tool with IPv6 compatibility that is syntactically similar to the traditional Netcat. socat comes with enhanced functionality built in that we can leverage to form bidirectional byte streams in order to tunnel our tools over IPv6. This works by opening a TCP socket listening on an IPv4 address and then forwarding all traffic received to a TCP socket listening on an IPv6 address. Let's instantiate a socat IPv4IPv6 tunnel, and verify that it is running:
socat IPv4IPv6 tunnel:
socat TCP4-LISTEN:80,fork,su=nobody TCP6:[2000::1:215:5dff:fe01:247]:80
Command Breakdown
socat TCP4-LISTEN:80,fork,su=nobody TCP6:[2000::1:215:5dff:fe01:247]:80
1. socat - Command line tool that establishes bidirectional byte streams
2. TCP4-LISTEN:80 - Specifies TCP port to receive incoming data
3. fork - Forks a child process for each established connection
4. su=nobody - Runs each forked process as an unprivileged user
5. TCP6:[2000::..:247] - Remote destination to connect to
6. :80 - Remote port to connect to
This creates an IPv4 socket on port 80 listening on all interfaces. SOCAT will forward any traffic received on port 80 by the local system to port 80 on the remote system at "2000::1:215:5dff:fe01:247".
Using "nc" to make a "GET" request we see the same result returned for the remote IPv6 web server. The first command points to the localhost SOCAT redirector which forwards the traffic over IPv6. The second is a direct netcat connection over IPv6 to "2000::1:215:5dff:fe01:247". Now let's give Nikto a try:
Now that the tunnel is running. We can examine the traffic to see what is happening in the background. This is the traffic coming out of the pentester's system on eth0 during the Nikto scan. You can see the traffic traversing over IPv6 as expected:
You can use SOCAT in much the same manner you would use SSH tunneling. Below is a screenshot of a browser accessing localhost over port 80. Here, SOCAT forwards the traffic to a remote IPv6 address for us enabling access to the metasploitable2 home page. SOCAT also natively supports socks proxying by way of the SOCKS4A option. SOCAT redirectors can be chained together to further enable network mobility or even covert operations.
Gotcha
There is one "gotcha" with this technique. When you are communicating over the link local interface you must tell the machine which interface you are using. This changes our SOCAT syntax to look something like this:
socat local link tunnel:
socat TCP4-LISTEN:445,fork TCP6:[fe80::2d24:c19c:892:4d3%wlp1s0]:445
Notice that the desired link local interface must be added to the target address in the command above ( "wlp1s0" in this case). Link local addresses only work within the layer 2 domain of the interface. In IPv4 terms this behavior is similar to ARP broadcast domains. If an ARP broadcast would touch the interface, you will be able to use an interface's link local address.
This is a handy technique to keep in mind while pentesting because almost all operating systems enable IPv6 by default. A network may have limited layer 3 IPv4 connectivity due to segmentation and filtering, but you just might be able to connect to an IPv6 link local address.
Hopefully IPv6 and the options available make a bit more sense now! The next chance you get, I heartily recommend taking a look around for the presence of IPv6. Network engineers are still coming to terms with the security implications to their networks. For pentesters this opens a world of vulnerability possibilities and you never know what you might find... until you do.
Matthew Toussain
https://twitter.com/0sm0s1z
