IPv6 Connection Hijacking and Scanning
by Farhan Al-Murādabādī
In this guide, I am going to explain how to redirect a user's connection to an arbitrary location and perform a practical network scan using IPv6. To understand the following content, the reader should be familiar with basic routing and IPv6 concepts.
Some Background Information
If you are not aware, the Internet is moving from the current IPv4 (32-bit) addressing system to the IPv6 (128-bit) addressing system.
In theory, this means 2128-1 possible addresses, although most of that is wasted on routing. IPv6 is not simply a new addressing system, it comes with a robust suite of protocols to facilitate deployment schemes, transition, and configuration.
One of the protocols is known as IPv6 Router Advertisement.
This protocol allows new clients on a network to receive the network prefix and router address without having to send out a DHCP request. This is performed by having a Router Advertisement daemon periodically emit a packet containing the 64-bit network prefix and the gateway address at semi-regular intervals. When a client machine intercepts the router solicitation packet, it auto-configures itself with the advertised information, thus allowing it to connect to the IPv6 Internet.
From an administrator's perspective, the main difference between this and DHCP over IPv4 is that clients do not need to alert every node on the network when they connect. Instead, a central server pushes out that information and updates are instantaneous.
Most modern operating systems automatically configure themselves upon receiving an IPv6 auto-configuration packet, including Windows, Linux, and FreeBSD. Many systems, including Windows, will prefer IPv6 over IPv4.
This means that if a DNS query returns both an A record (IPv4) and an AAAA record (IPv6), it will prefer the IPv6 address before even attempting IPv4. Auto-configuration generally occurs without prompting the user. This is different than DHCP, where the user usually has to initiate the configuration in some way.
Currently, very few North American networks deploy IPv6. Most leave their IPv6 stacks latently unconfigured and have zero security around them.
Traffic Redirection Exploit
Can you already smell the vulnerability?
A latent IPv6 stack is a goldmine for attackers. An attacker must simply deploy a router advertising daemon on a target network to have victims route IPv6 traffic through his self-assigned IPv6 gateway. From there, he can re-route or modify the traffic as he wishes.
The following is a step-by-step guide of how to do this in BackTrack Linux:
1.) Assign yourself an IPv6 address as follows:
2.) Turn on IPv6 routing as follows:
3.) Download and install the Linux IPv6 Router Advertisement Daemon called radvd.
4.) Configure the /etc/radvd.conf file to be something like:
interface eth0 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2001:DB8:DEAD:C0DE::/32 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; };Now execute radvd as root and use radvdump, another tool, to ensure that advertisements were sent out. With even a single packet, target clients on the network should have auto-configured themselves, so if you are worried about getting noticed, now would be a good time to kill radvd!
At this point, you should have the entire network routing its IPv6 traffic through 2001:DB8:DEAD:C0DE::1, which is you.
Now the real fun begins!
When an IPv6 packet hits your kernel that does not belong to it, and no route is defined in the routing table, the kernel should respond with an ICMP "No Route to Host" packet, meaning, "This does not belong to me, and I don't know where to forward it."
However, in this case, we want to claim packets that do not necessarily belong to us as our own. The best way to do this is to set your interface's address to the remote host you are trying to fake.
For example, if you were trying to intercept data destined to 2001:DB8:A11A:4::1, you would do:
Now, when a user connects to 2001:DB8:A11A:4::1, the packets will be accepted by your machine.
At this point, you can set up a fake web server or mail server! Whatever is your fancy!
There is a problem with this: the vast majority of domain names do not use IPv6, and those that do use IPv6-specific hostnames, such as IPv6.google.com or IPv6.netflix.com.
However, if the radvd folks decide to implement the experimental RFC 5006, allowing for DNS configuration, this will allow you to configure your targets with a malicious DNS server that manually sets the AAAA records of target sites. Such an attacker would have a lot more power.
Scanning an IPv6 Network
On a traditional IPv4 network, scanning even a Class B network is a trivial exercise with Nmap.
However, given that site-level networks in IPv6 are 64-bits (larger than the entire IPv4 Internet), a scan would be completely impractical.
Therefore, hackers are forced to find alternative ways to perform site-level scans. Here are a few:
1.) ping the multicast: One of the simplest ways is to ping the IPv6 multicast address and collect the link-local responses. This can easily be done by doing:
It is worth mentioning that most Windows IPv6 stacks do not respond to IPv6 pings by default.
2.) IPv6 link-local addresses prediction: link-local addresses are logically assigned based off of the MAC address on the interface card.
If you can discern the hardware manufacturer of the target network, you can reduce the range you have to scan by millions.
If your MAC address is 00:12:34:56:78:9A, this means your link-local address should be FE80::12:34FF:FE56:789A.
And since the first three bytes of the MAC address (the organizationally unique identifier) are specific to a hardware manufacturer, you really only have three bytes of address space to scan.
For example, if you are scanning a network whose hardware manufacturer is Novus Security, its link-local addresses should be FE80::1B:9DFF:FE:XX:YY:ZZ, where XX, YY, and ZZ are the bytes in question.
That reduces your scan from 64-bits to 48-bits. That's still a lot. But if the hardware manufacturer distributed the hardware sequentially, you might be able to narrow it down further.
3.) While not quite the same, many IPv6 stacks automatically assign 6to4 tunnel addresses when they detect that the address they have been assigned is Internet routable.
These are addresses that are designed to help with the transition over to IPv6.
They come in the following two formats: 2002:V4ADDR::1 or 2002:V4ADDR::V4ADDR, where V4ADDR is the IPv4 address in hexadecimal of the machine.
An attacker could perform a scan on the 6to4 addresses. However, this would be very similar to a traditional IPv4 scan, and would likely even be picked up by IDS systems that do not check for IPv6.
4.) Guess! Well, not quite. If you notice a pattern of either manually assigned or sequential addresses, then that should substantially narrow down your scanning range.
Closing
IPv6 is vastly underutilized in the U.S. and, as mentioned earlier, a latent unconfigured IPv6 stack is a goldmine for hackers. This is just a short explanation of the many security holes that IPv6 potentially yields in networks.
In my opinion, the best way to prevent against this kind of attack is to either turn off Router Discovery on the clients (best done through a Windows GPO) or filter unsolicited packets at the switch-level. And if you do perform an attack, just imagine a clueless network administrator's surprise when he checks his logs and says, "That attack came from where?!"
In closing, free Tarek Mehanna and Ahmed Omar Abu Ali! They are both victims of the post-9/11 hysteria!