As IPv6\u2019s popularity has grown and its usage on the Internet has increased, it has caught the attention of attackers.\u00a0 Typically, targeted attacks begin with reconnaissance to first identify the victim.\u00a0 Then active network scanning and exploring leads to exploitation of the target.\u00a0 This is followed by the attacker maintaining access, covering their tracks, and leveraging that access to pivot to additional targets.\u00a0 With the finite limits of IPv4 addresses and their high density and utilization, reconnaissance of all public IPv4 addresses is commonplace.\u00a0 However, IPv6, in theory, may change how Internet reconnaissance is performed.<\/p>\n
Previously, it was believed that the vastness of IPv6\u2019s address space made scanning too difficult, if not impossible.\u00a0 For a remote attacker, it may be too difficult to even find the \/64s assigned to individual access networks.\u00a0 For example, if an enterprise organization is allocated a \/32 from a Regional Internet Registry<\/a> (RIR), they could theoretically have 2^32 \/64 prefixes, equal to 4,294,967,296 possible \/64 prefixes (~4.3B prefixes).<\/p>\n Remotely finding the network \/64 prefix is one thing but finding all the individual end-nodes\u2019 complete 128-bit global unicast IPv6 addresses is another.\u00a0 It was also previously believed that even link-local IPv6 reconnaissance was nearly impossible.\u00a0 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.<\/p>\n If the attacker were to perform a brute-force scan of all possible link-local IPv6 nodes, it could take an astronomically long time.\u00a0 A single IPv6 \/64 prefix has 2^64 possible theoretical addresses.\u00a0 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.\u00a0 Attackers can be patient, but that would be ridiculous.<\/p>\n Remote and link-local brute-force IPv6 reconnaissance has been rightfully considered too time-consuming.\u00a0 But creative security researchers and attackers have discovered methods to intelligently perform \u201cinformed scanning\u201d to reduce the time it takes.<\/p>\n 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.).\u00a0 If a target network simply uses the last octet of their node\u2019s 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.<\/p>\n Finding network segments would also be trivial if the network (i.e., the high-order 64-bits) prefix used sequential IPv6 prefix assignments.\u00a0 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.<\/p>\n Link-local reconnaissance is also trivial.\u00a0 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.\u00a0 The attacker would also assume that all IPv6-enabled nodes on the network have an fe80::\/10 link-local address.\u00a0 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<\/a> (FHS) measures can mitigate that last threat).<\/p>\n Organizations may want nodes to have static (or stable<\/a>) IPv6 addresses for simpler proactive management or security functions like reputation systems.\u00a0 The hope is that having sparse prefixes and randomized IIDs helps preserve privacy and avoids active probing reconnaissance by adversaries.\u00a0 However, as outlined below, these could still be discovered.<\/p>\n Creativity is one characteristic that separates us humans from our AI-fueled robot overlords.\u00a0 For more than a decade now, security researchers have been inventing a variety of alternative methods to find IPv6 targets. \u00a0Fernando Gont<\/a> and Tim Chown<\/a> authored an IETF RFC, Network Reconnaissance in IPv6 Networks<\/a> (RFC 7707), that discusses the concepts surrounding how attackers could find IPv6 targets.\u00a0 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.\u00a0 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.\u00a0 One could also use SNMP to query routers for their IPv6 neighbor caches or look in other IPv6 nodes\u2019 neighbor caches to find target addresses.<\/p>\n Attackers, by their very nature, will be creative in their approaches.\u00a0 When performing network reconnaissance, it is important to remember that anything that elicits a response reveals that something is there.\u00a0 The attacker doesn\u2019t 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.<\/p>\n Prior to RFC 7707\u2019s publication in 2016, some other innovative approaches to remote reconnaissance network scanning emerged.\u00a0 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.\u00a0 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<\/a> (Code 0 hop limit exceeded in transit) messages. \u00a0Paris Traceroute<\/a> methods (like those implemented in Scamper<\/a>) can also find multiple alternate paths to a destination and identify more IPv6 addresses along the way.<\/p>\n Another creative approach to finding IPv6 networks on the Internet is what is called the \u201cToo Big Trick (TBT)\u201d.\u00a0 This technique involves sending a 1300-byte ICMP6 Type 128 Echo Request<\/a> to some network on the Internet.\u00a0 When the router sends back the ICMPv6 Type 129 Echo Reply<\/a>, it is ignored and the attacker sends an ICMP6 Type 2 Packet Too Big<\/a> message with a MTU lower than 1300 bytes.\u00a0 The attacker then sends a new ICMPv6 Echo Request and observes that the router sends back a fragmented ICMPv6 Echo Reply.\u00a0 The attacker can then probe beyond that router and observe the fragmentation identifiers of the subsequent ICMPv6 Echo Requests.\u00a0 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 \u201cIPv6 Alias Resolution via Induced Fragmentation<\/a>\u201d (and presentation<\/a>).\u00a0 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<\/a> and Scamper<\/a>.\u00a0 This PTB technique and its implications on load balancers and anycast services was also documented in IETF RFC 7690, \u201cClose Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))<\/a>\u201d.<\/p>\n 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.\u00a0 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<\/a> (top 1M most popular domains), the Majestic Million<\/a> (the million domains with the most referring subnets) (.CSV file<\/a>), or the ICANN Centralized Zone Data Service<\/a> (CZDS) (> 300M domains).<\/p>\n Attackers can perform a DNS query for a FQDN with an IPv4 A record and an IPv6 AAAA record.\u00a0 This might indicate that the target host has both IPv4 and IPv6 but that isn\u2019t necessarily the case.\u00a0 The attacker could then run a traceroute to both addresses to reveal if the network topology is congruent.\u00a0 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.\u00a0 These techniques were written about in \u201cServer Siblings: Identifying Shared IPv4\/IPv6 Infrastructure via Active Fingerprinting<\/a>\u201d by Robert Beverly and Arthur Berger.<\/p>\n Another technique is where the attacker performs reverse DNS enumeration by doing DNS queries for PTR records for IPv6 addresses.\u00a0 IPv6 reverse DNS \u201cPTR\u201d 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.\u00a0 Peter van Dijk wrote about this on March 26, 2012 in \u201cFinding v6 hosts by efficiently mapping ip6.arpa<\/a>\u201d and on April 8, 2012 in \u201cip6.arpa, prior art and results<\/a>\u201d.\u00a0 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\u2019t exist in the DNS and that there can be no other longer prefix.\u00a0 However, if the DNS server returns a NOERROR error, then there might be a longer prefix that could be queried.\u00a0 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.<\/p>\nTrivial Reconnaissance<\/h3>\n
Creative Reconnaissance<\/h3>\n
Leveraging DNS to Find IPv6 Targets<\/h3>\n
Part 2<\/h3>\n