As a networking student I remember reading about IPv6 and its imminent introduction on more than one occasion. Articles predicting the complete depletion of the IPv4 address space were plenty and you could be forgiven for thinking that IPv4 would simply disappear overnight and be replaced with the new protocol. This didn’t turn out to be the case, you could still obtain IPv4 addresses, albeit requiring greater justification, whilst the introduction of technologies such as carrier grade NAT eked further life out of the protocol. In fact, according to Google, IPv6 traffic still accounted for less than 1% of all internet traffic as of January 2013. Because of this low uptake, penetration testers, including myself, spent little time exploring IPv6 and its operation.
Fast forward to today and IPv6 is a subject that we, as penetration testers, need to take cognisance of. Deployments of the protocol are on the increase and a potential lack of understanding could present attackers with an area of exploitation. Additionally, testing techniques and methodologies will require modification in order to provide clients with penetration tests which properly investigate IPv6 functionality on their networks.
Address Structure
The first obvious difference between IPv4 and IPv6 is the address structure. With IPv4 we have been used to working with decimal address notation. Addresses are split into four octets, each representing 8 bits and giving a 32 bit address. This structure allows for a theoretical maximum of 232 addresses or approximately 4 billion unique addresses if you prefer. IPv6 on the other hand uses hexadecimal notation with eight banks of four character hexadecimal numbers. This structure is separated by colons and gives us a 128 bit address with a potential 2128 addresses or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses! The size of the address space is vast and that is something that we will look at in the context of a penetration test.
2001:DDB8:AAAA:FA41:CAFE:4531:E3FE:1111
Example of an IPv6 address
Scanning IPv6 Networks
Scanning and host discovery presents penetration testers with a headache in that IPv6 networks are vast, so vast that a /64 network would take around 28 years to discover the first host by using conventional means. Add to this the fact that even if time permitted, scanning tools such as NMAP do not even allow us to scan an entire IPv6 subnet. Both time and the lack of a suitable tool rules out traditional blind scanning techniques which testers utilise on IPv4 networks. So how can these IPv6 networks be scanned?
Luckily IPv6 has protocols which can be leveraged in order to discover hosts on an internal network. In IPv6, hosts send ICMPv6 Router Solicitation (RS) messages to the all router multicast address (ff02::2) and Neighbour Solicitation (NS) messages to the all nodes multicast address (ff02::1). Routers respond to RS messages with Router Advertisement (RA) messages which contain the default router address, as well as information on how a host should assign its IPv6 address. IPv6 nodes on the other hand will respond to NS messages with Neighbour Advertisement (NA) messages, containing their network interface’s IPv6 address, similar to the functionality of ARP in IPv4. It is these NS and NA messages that we can leverage to discover hosts on an internal network.
By sending an ICMPv6 ping request to the all nodes multicast address, as shown below, we can observe the responses, giving us the link-local IPv6 address of each node.
~$ping6 –I enp0s3 –c 2 ff02::1 PING ff02::1(ff02::1) from fe80::6ea:132b:3474:8d72 enp0s3: 56 data bytes 64 bytes from fe80::6ea:132b:3474:8d72: icmp_seq=1 ttl=64 time=0.022 ms 64 bytes from fe80::1a95:9451:7d56:cfdf: icmp_seq=1 ttl=64 time=1.50 ms (DUP!) 64 bytes from fe80::4b0d:34fc:fe0b:2641: icmp_seq=1 ttl=64 time=1.52 ms (DUP!) 64 bytes from fe80::64f8:9ac9:7fec:a83e: icmp_seq=1 ttl=64 time=1.52 ms (DUP!) 64 bytes from fe80::a00:27ff:fe6e:d7a4: icmp_seq=1 ttl=64 time=1.64 ms (DUP!) 64 bytes from fe80::6ea:132b:3474:8d72: icmp_seq=1 ttl=64 time=1.64 ms
You will notice how some addresses in the output are flagged with “(DUP!)”. Now, if you look up the Ping6 man page these flags may indicate malformed or duplicate packets, however, in our case this is the expected behaviour as we pinged the multicast address. Furthermore, we can use these to make reconnaissance easy as they allow us to remove our own interface address from the output.
By using the following Bash “one-liner” (where –I is our interface), we can grab the output that we require to perform an NMAP scan.
~$ping6 -I enp0s3 -c 2 ff02::1 | grep DUP | awk '{print substr($4, 1, length($4)-1)}' > ipv6_hosts.txt
In order to perform a port scan on these addresses, it is simply a case of running our preferred NMAP command against the file created. This is the same command you may use in IPv4 but with the “-6” flag set as shown below. Note the “-e” flag, NMAP will through an error if you scan against IPv6 link-local addresses without this set.
~$nmap -6 –e enp0s3 –vv -F -sV –iL ipv6_hosts.txt
We have established that the network size in IPv6 needn’t be a hindrance when it comes to scanning internal networks, but what about external network scanning?
Scanning IPv6 networks from an external viewpoint strips us of the protocols that make scanning internal IPv6 networks more straightforward. Externally, these protocols shouldn’t be running leaving us in a position of difficulty when trying to discover hosts. One solution is to scan from inventory, by asking the client for a list of hosts we can easily perform scanning. Whilst this is one potential solution it doesn’t account for a large number of clients who wish to approach their testing with a black box approach. Thankfully, there are some features of IPv6 itself and some traits of human behaviour that we can use in order to reduce the scan scope and make scanning external IPv6 networks possible.
The first area to look at is the way IPv6 addresses can be automatically generated by hosts. Stateless Auto Configuration (SLAAC) is used by hosts to generate an IPv6 address from the network prefix. One such way that that this can be achieved is by using the RS and RA exchange to obtain the IPv6 prefix and then forming the interface ID by splitting the 48 bit MAC address into two 24 bit sections and inserting the 16bit FFFE reserved value in between. This affords an opportunity for us to narrow the scan scope by scanning IPv6 addresses in respect of the manufacturer of the NIC card. By utilising the Scan6 tool from the excellent IPv6 Toolkit it is possible for us to run the following command, and only scan addresses with an EUI-64 ID created from a Dell NIC.
~$scan6 -i ep0s3 -d 2001:db8::/64 –K ‘Dell Inc’
By using the same philosophy it is also possible to perform scans against only virtual machine hosts. The following command allows us to scan only IPv6 addresses with interface IDs created by VirtualBox hosts.
~$scan6 -i ep0s3 -d 2001:db8::/64 –K ‘vbox’
Finally Scan6 offers the ability to scan for what are described as low byte addresses. Such addresses are created manually by system administrators and typically follow a pattern. For example an administrator may assign the 2001:0DB8:CAFE: 1::1 address to a router, then assign 2001:0DB8:CAFE: 1::2 to the first host and so on. By using the following command Scan6 will scan only these low byte addresses, significantly reducing scan times.
~$scan6 -i ep0s3 -d 2001:db8::/64 -b
Whilst these techniques to reduce scan scope are effective, it should be noted that if employing them on a test it may be possible to miss live hosts, if hosts are assigned randomly for example. Additionally, the introduction of privacy extensions to create random interface IDs will render all but the low byte address technique redundant in time.
Final Word
Scanning IPv6 networks requires a little bit of thought. Whilst network scanning is unlikely to be adversely affected by the protocol’s introduction from an internal viewpoint, it is possible that blind network discovery exercises will no longer be possible externally.