As IPv6’s popularity has grown and its usage on the Internet has increased, it has caught the attention of attackers. Typically, targeted attacks begin with reconnaissance to first identify the victim. Then active network scanning and exploring leads to exploitation of the target. This is followed by the attacker maintaining access, covering their tracks, and leveraging that access to pivot to additional targets. With the finite limits of IPv4 addresses and their high density and utilization, reconnaissance of all public IPv4 addresses is commonplace. However, IPv6, in theory, may change how Internet reconnaissance is performed.
IPv6: Too Big to Scan?
Previously, it was believed that the vastness of IPv6’s address space made scanning too difficult, if not impossible. For a remote attacker, it may be too difficult to even find the /64s assigned to individual access networks. For example, if an enterprise organization is allocated a /32 from a Regional Internet Registry (RIR), they could theoretically have 2^32 /64 prefixes, equal to 4,294,967,296 possible /64 prefixes (~4.3B prefixes).
Remotely finding the network /64 prefix is one thing but finding all the individual end-nodes’ complete 128-bit global unicast IPv6 addresses is another. It was also previously believed that even link-local IPv6 reconnaissance was nearly impossible. Local reconnaissance is when the attacker has direct access to the link or has compromised a system that is on the local LAN and the attacker attempts to find other nodes on the same segment.
If the attacker were to perform a brute-force scan of all possible link-local IPv6 nodes, it could take an astronomically long time. A single IPv6 /64 prefix has 2^64 possible theoretical addresses. Trying to scan 18,446,744,073,709,551,616 addresses at a rate of 1,000,000 probes/second would take 18,446,744,073,709 seconds, which equals 584,942 years. Attackers can be patient, but that would be ridiculous.
Remote and link-local brute-force IPv6 reconnaissance has been rightfully considered too time-consuming. But creative security researchers and attackers have discovered methods to intelligently perform “informed scanning” to reduce the time it takes.
Trivial Reconnaissance
IPv6 reconnaissance can be trivial if the target uses an IPv6 address with an Interface Identifier (IID) where the last least-significant 64-bits are low and sequential (e.g., ::, ::1, ::2, ::3, ::4, etc.). If a target network simply uses the last octet of their node’s IPv4 address and uses those 3 digits to form the last 3 hexadecimal digits of the IPv6 IID (e.g., 192.168.10.123/24, 2001:db8:10:10::123/64), then the attacker would only need to scan 254 IPv6 addresses.
Finding network segments would also be trivial if the network (i.e., the high-order 64-bits) prefix used sequential IPv6 prefix assignments. For example, if an organization has been allocated 2001:db8:1100::/40 and the first subnet is assigned 2001:db8:1100:1::/64, the second subnet is assigned 2001:db8:1100:2::/64, and the third uses 2001:db8:1100:3::/64, then reconnaissance is easy.
Link-local reconnaissance is also trivial. If the attacker is on-link, they could easily learn the /64 prefix by observing a Router Advertisement (RA) or observing any traffic traversing the LAN. The attacker would also assume that all IPv6-enabled nodes on the network have an fe80::/10 link-local address. The attacker could easily find nodes that respond to ICMPv6 messages sent to the ff02::1 link-local all-nodes multicast group (e.g., Linux hosts). Or the attacker could simply send a rogue RA and glean information about the nodes that activated their IPv6 stacks (although IPv6 First-Hop-Security (FHS) measures can mitigate that last threat).
Organizations may want nodes to have static (or stable) IPv6 addresses for simpler proactive management or security functions like reputation systems. The hope is that having sparse prefixes and randomized IIDs helps preserve privacy and avoids active probing reconnaissance by adversaries. However, as outlined below, these could still be discovered.
Creative Reconnaissance
Creativity is one characteristic that separates us humans from our AI-fueled robot overlords. For more than a decade now, security researchers have been inventing a variety of alternative methods to find IPv6 targets. Fernando Gont and Tim Chown authored an IETF RFC, Network Reconnaissance in IPv6 Networks (RFC 7707), that discusses the concepts surrounding how attackers could find IPv6 targets. This RFC discusses how an attacker could be on the local access network scanning for nodes or how the attacker could be more than one layer-3 hop away or across the Internet performing remote reconnaissance. Of course, attackers could find IPv6 addresses in other places, like DNS, logs, DHCPv6 server databases, Google hacking, online forums, packet capture snooping, and observing flow data. One could also use SNMP to query routers for their IPv6 neighbor caches or look in other IPv6 nodes’ neighbor caches to find target addresses.
Attackers, by their very nature, will be creative in their approaches. When performing network reconnaissance, it is important to remember that anything that elicits a response reveals that something is there. The attacker doesn’t need to generate a legitimate packet so long as the victim sends back an error message in return. The attacker observes the source address in the returned packet and now has a valuable piece of information to continue the attack process.
Prior to RFC 7707’s publication in 2016, some other innovative approaches to remote reconnaissance network scanning emerged. One technique is akin to depth-finding on a boat. This method explores the IPv6 Internet one hop at a time by sending packets that increase IPv6 header Hop Limit values. This is like the method traceroute uses to find addresses along a path and evaluating the types of addresses that return ICMPv6 Type 3 Time Exceeded (Code 0 hop limit exceeded in transit) messages. Paris Traceroute methods (like those implemented in Scamper) can also find multiple alternate paths to a destination and identify more IPv6 addresses along the way.
Another creative approach to finding IPv6 networks on the Internet is what is called the “Too Big Trick (TBT)”. This technique involves sending a 1300-byte ICMP6 Type 128 Echo Request to some network on the Internet. When the router sends back the ICMPv6 Type 129 Echo Reply, it is ignored and the attacker sends an ICMP6 Type 2 Packet Too Big message with a MTU lower than 1300 bytes. The attacker then sends a new ICMPv6 Echo Request and observes that the router sends back a fragmented ICMPv6 Echo Reply. The attacker can then probe beyond that router and observe the fragmentation identifiers of the subsequent ICMPv6 Echo Requests. Billy Brinkmeyer, Robert Beverly, and Justin Rohrer from the Naval Postgraduate School (NPS), along with Matthew Luckie from CAIDA at the University of California San Diego, wrote about this technique in their 2013 paper titled “IPv6 Alias Resolution via Induced Fragmentation” (and presentation). This technique of mapping out networks with ICMPv6 Type 2 Packet Too Big (PTB) Messages can be used for remote reconnaissance and these techniques are implemented in the tools tbt.py and Scamper. This PTB technique and its implications on load balancers and anycast services was also documented in IETF RFC 7690, “Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))”.
Leveraging DNS to Find IPv6 Targets
Next, we can assume that any entries put into Internet-accessible DNS resource records are intended to be found and that attackers could find this information as well. Attackers can find domain names easily enough if they know their intended target domain name; or if they can learn it from the Cisco Umbrella 1 Million (top 1M most popular domains), the Majestic Million (the million domains with the most referring subnets) (.CSV file), or the ICANN Centralized Zone Data Service (CZDS) (> 300M domains).
Attackers can perform a DNS query for a FQDN with an IPv4 A record and an IPv6 AAAA record. This might indicate that the target host has both IPv4 and IPv6 but that isn’t necessarily the case. The attacker could then run a traceroute to both addresses to reveal if the network topology is congruent. The attacker could also perform host OS fingerprinting or TCP timestamp time drift analysis to determine if the IPv4 and IPv6 address are on the same target host. These techniques were written about in “Server Siblings: Identifying Shared IPv4/IPv6 Infrastructure via Active Fingerprinting” by Robert Beverly and Arthur Berger.
Another technique is where the attacker performs reverse DNS enumeration by doing DNS queries for PTR records for IPv6 addresses. IPv6 reverse DNS “PTR” records are in reverse zone files using the name of the IPv6 prefix. For example, 2001:db8:80::/48 file would be named 0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Peter van Dijk wrote about this on March 26, 2012 in “Finding v6 hosts by efficiently mapping ip6.arpa” and on April 8, 2012 in “ip6.arpa, prior art and results”. When the attacker queries the authoritative DNS server for the IPv6 prefix and the DNS server returns a NXDOMAIN error, that indicates the prefix doesn’t exist in the DNS and that there can be no other longer prefix. However, if the DNS server returns a NOERROR error, then there might be a longer prefix that could be queried. Attackers can work diligently to map out different lengths of queries to try to determine which IPv6 prefixes are populated in reverse DNS zone files.
Part 2
The second part of this article will discuss how attackers and security researchers can create lists of reachable IPv6 addresses or try to predict which IPv6 addresses are likely to exist. Then it will cover the tools that can be used for IPv6 Internet scanning and recently detected scanning activities.
