There are many topics that fall under the heading of “How is the IPv6 protocol that I am less familiar with different than the IPv4 protocol that I know very well?” By now, readers of the Infoblox IPv6 Center of Excellence community blog should be familiar with several of the major differences between IPv4 and IPv6. Among these differences are the packet header format, addressing format, extension headers, neighbor discovery protocol, DHCP server redundancy, among other protocol characteristics. There are also several important distinctions between how security vulnerability scanning is performed for IPv4 and IPv6 nodes. This article will highlight these variations so you are prepared to evaluate your IPv6 security as your organization moves forward with its IPv6 deployment.
Security Vulnerability Scanning
Typical security vulnerability scanners like Qualys QualysGuard, Rapid7 Nexpose, Tenable Nessus, among numerous others, send packets to IP addresses on local or remote networks and record what gets returned. They try to send packets to systems in order to discover nodes on the networks and detect if they can establish connections to services listening on specific open TCP or UDP ports. This basic port scanning function is the lowest common denominator among all products. The vulnerability scanners come with pre-loaded and constantly updated known vulnerabilities that are tested and provide reports of known weaknesses in the environment. Other scanners have more advanced functionality, like performing web application scanning and looking for the OWASP top 10 web application risks. Vulnerability scanners can perform credentialed scans of computers based on known authorized usernames and passwords to inspect the internal configuration of the target system. Performing continuous vulnerability assessments is number 4 on the SANS/CIS 20 Critical Security Controls (CSCs).
Some methods of performing vulnerability assessments involve putting an agent or software component on the device under test (DUT). That agent then reports back to a centralized system about the security settings on that computer. Agents, however, can be problematic. Enterprises may struggle with the challenges of loading an agent on all computers in the enterprise. Many computers are not within reach of the IT department and agents require updating and occasional troubleshooting.
Scanning IPv4 Networks
Historically, vulnerability scanners only had one IP version running on the network to perform remote testing. On an IPv4 network, the vulnerability scanning appliance or virtual scanning system can scan all the internal IPv4 addresses (e.g., 10.0.0.0/8, etc.). The vulnerability scanner will then proceed to constantly scan the network, or run scheduled scans that take hours or days to complete. The duration depends on the size of the network, the population density of the IP subnets, and the rigorousness of the scans.
We can perform a rough calculation of how long a scan might take. Let’s suppose that we want to sequentially scan an IPv4 /8 block with a total of 16,777,216 possible IPv4 addresses. If we started by only scanning for 30 popular TCP port numbers at a rate of 1000 packets-per-second (pps) then it would take 140 hours or about 6 days to complete. However, there are much faster scanners available that are optimized and multi-threaded for improved performance. There are even highly-optimized tools like ZMAP and MASSCAN that have the ability to generate tremendous amounts of scanning traffic. ZMAP and MASSCAN can be used to map out the entire public IPv4 address space in less than an hour.
Scanning IPv6 Networks
Now, let’s consider how IPv6 changes the scanning practice. The IPv6 address space is so immense that it is nearly impossible to scan each IPv6 address in a given subnet to try to determine if a node is using that address. For example, within a single /64 prefix, there are 18,446,744,073,709,551,616 (about 18 quintillion) unique interface identifiers (IIDs). As stated in IETF RFC 5157 “IPv6 Implications for Network Scanning”: “At a very conservative one probe per second, such a scan may take some 5 billion years to complete.” Hackers may be patient and persistent, but that is too much. (The IETF RFC 7707 titled “Network Reconnaissance in IPv6 Networks” obsoletes RFC 5157 and describes additional methods of reconnaissance that could be used by a vulnerability scanner.)
We should also mention that there are more intelligent methods of performing reconnaissance on a link-local segment. These methods offer improvements over the brute-force sequential scanning method. They might include, for example, the same techniques used to perform Internet worm propagation.
Reconnaissance scanning is trivial in the following situations:
- When nodes are allocated sequential IIDs addresses such as ::1, ::2, ::3, ::4, …
- When nodes have their IPv6 address in DNS zones that can be queried
- When nodes respond to an ICMPv6 echo-request sent to the all-nodes link-local multicast (FF02::1)
- When nodes respond to an invalid extension header sent to the all-nodes link-local multicast (FF02::1)
- When nodes respond to an MLD query send to the all-nodes link-local multicast (FF02::1)
- When nodes send an ICMPv6 type 135 Neighbor Solicitation (NS) for a rogue default router sending an ICMPv6 type 134 Router Advertisement (RA)
- Using other methods of leveraging IPv4 to learn the IPv6 address of the dual-protocol node
Reconnaissance is also easier to perform if all the nodes on the network use SLAAC and EUI-64 with the same Ethernet NIC OUI. In this case, the first 24 bits of the IID will all be the same, the next 16 bits of the IID are FFFE, followed by the unique 24 bits of the node’s MAC address. Scanning 224 IPv6 addresses might take only a few days. Reconnaissance can also be performed if the nodes are using 6to4, ISATAP, or Teredo with known IPv4 addresses.
Utilities like The Hacker’s Choice IPv6 Attack Toolkit, the SI6 Networks IPv6 Toolkit, Chiron, pfuzz, and Scapy scripts can perform these types of reconnaissance to learn the IPv6 addresses. Once the IPv6 addresses are known, then these can be used to more rigorously scan for vulnerabilities.
The speed of vulnerability scanning is related to the node population density. The population density is measured as the number of active hosts divided by the total number of possible addresses. For example, on an IPv4 network, there could be 100 active hosts on a /24 subnet with a total of 254 possible addresses for a density of .393. On an IPv6 /64 network with 100 active hosts the density would be .00000000000000000542. This is very near the equivalent of a finding a specific single grain of sand in the Sahara desert!
Not only are the subnets sparsely populated with nodes, but the subnets themselves are most often sparsely assigned. If an organization has been allocated a /36 as a large enterprise, that allows for 228 /64 prefixes (268,435,456). Remote scanning is even more difficult than on-link scanning where you can generate link-local multicast packets. With remote scanning you must have end-to-end IPv6 reachability to the scanning target. This might be difficult to achieve if there is a firewall or IPS in the path. Furthermore, most enterprises do not yet have end-to-end IPv6 reachability for their corporate LAN clients and data center servers.
IPv6-Capable Vulnerability Scanners
Because of the immensity of the IPv6 address space, most scanning utilities do not even permit the user to attempt to perform a scan on an entire /64, much less an entire /40 prefix that might have been allocated to an enterprise by an RIR. Furthermore, tools like ZMAP and MASSCAN do not even support IPv6.
The first question to ask is, “do any of my existing vulnerability scanners support IPv6?” More precisely, do they have feature and functional parity between IPv4 and IPv6? In other words, for the tasks they perform in IPv4, are they able to perform those same tasks for IPv6? As mentioned earlier, there are different types of security scanners. They range from the most basic port scanners to the most advanced web application and database scanners. If they only perform basic scanning of open ports for IPv6, but do much more in-depth application scanning for IPv4, then you lack the functionality (i.e., functional parity) you really need. This is why it is important to ask your vendors about IPv4 and IPv6 functional parity of their products. Surely any modern product that has just been developed and released should have IPv6 capabilities right from the start.
One of the major considerations of IPv4 vulnerability scanners is cost, given that they have historically been licensed based on the number of IPv4 addresses that you can scan. If you purchased a license for 256 IP addresses, then you are limited to scanning a /24 IPv4 subnet or a specific list of 256 hosts. However, with IPv6, the subnet ranges are so much larger (albeit extremely sparsely populated) that this software licensing model breaks down.
The good news is that most port scanners and vulnerability scanners already support IPv6. Security vulnerability scanning products like those mentioned earlier (Qualys, Rapid7, and Tenable) all support IPv6. However, they need to be provided a list of individual IPv6 addresses to scan. A proper vulnerability scanner shouldn’t make you enter each one manually. In fact, most vulnerability scanners let you add in a list of IPv6 addresses, either as a big list/text file, or a CSV file. Therefore, we must first obtain a list of the individual IPv6 addresses to be scanned.
Determining the IPv6 Addresses
When you have an IPv6-capable vulnerability scanner that can scan individual IPv6 addresses, the next step is to assemble the list of all active IPv6 nodes in the environment.
One method of creating this list might be to scrape all the routers for their MAC address tables (ARP table, neighbor cache) to find all the connected devices. One way to gather this information is from the routers themselves using the CLI. You can use commands such as “show ipv6 neighbors” or “show ipv6 neighbor binding” on a Cisco device to learn the active connected nodes. This could be automated with a simple Python script. Another option may be to use SNMP to query MIB values of the routers to gather their neighbor cache entries. The trick here is finding the correct MIB OID value to query (or just performing an SNMP walk of the device).
Another way to discover active IPv6 addresses is to perform a bulk lease query of the DHCPv6 server to gather a list of the active IPv6 address leases. With an Infoblox appliance, you can view the DHCP lease history data. The NIOS Administrator Guide shows you how you can use the web interface of the Grid Manager by selecting the “Data Management” tab, then selecting the “DHCP” tab, then clicking on the “Leases” tab and then “Lease History”. You can also export the lease records by clicking on the “Export” icon and proceeding to download the CSV file. This can then be used with your favorite vulnerability scanner to input the list of IPv6 addresses to scan.
You could also use Infoblox Network Insight to discover what is connected to your network. Network Insight can automatically share address information with Infoblox IPAM system. The Insight Manager integrates with Cisco’s Identity Services Engine (ISE), sharing data related to endpoints and connectivity with Cisco’s Platform Exchange Grid (pxGrid). Cisco ISE 2.0 now supports IPv6. Network Insight also integrates with popular vulnerability scanners to speed up the sharing of data between platforms. There are even RESTful APIs that can be used with Python scripts to automate operation of Network Insight.
Correlating the Two Address Families
One of the challenges with operating a dual-protocol network that we do not yet have a good solution for today is how to equate IPv4 and IPv6 security information for a given host. If your organization uses a Security Information Event Management (SIEM) system in a dual-protocol environment, then you need it to be cognizant about which hosts have both IPv4 and IPv6 addresses. There are significant challenges around correlating findings for systems that used both IPv4 and IPv6. Using multiple address families to conduct an attack could be a sophisticated strategy used by attackers to evade detection. Imagine a piece of malware that infects one host over an IPv4 web vulnerability, but then uses IPv6 to spread to other nodes on the local LAN, and those newly infected nodes use either IPv4 or IPv6 to communicate to a botnet command and control network. Correlating those attack trajectories is daunting.
This same concept also applies to security vulnerability scanning. How does the scanner know that the node with the IPv4 address of 10.45.73.56 is the same node with the IPv6 address 2001:db8:476:34:8d94:d36b:7bfd:7e27? A scanner may not be able to correlate information across address families. However, agent-based approaches may be aware that the node has both an IPv4 and an IPv6 address.
What we need is an IP address management (IPAM) system that can correlate MAC addresses and DHCP Unique Identifiers (DUIDs) with DHCP/DHCPv6 lease information, while at the same time inspecting the network Ethernet switch ports and sharing this data with a SIEM. We need security systems that are integrated and collaboratively share information to help create the most effective enterprise security platform.
Summary
As your organization begins to deploy IPv6 you will need to test the IPv6 attack surface, just as you check for IPv4 security vulnerabilities. You will likely start your IPv6 deployment at the perimeter so it is those Internet-facing systems that will be first exposed. As a result, you will need to scan these systems first. You will need a vulnerability scanner that is also capable of testing for web application vulnerabilities with the most current known vulnerability information.
Initially, your Internet-edge IPv6 deployment will use static IPv6 addresses, so knowing which nodes and the corresponding IP addresses that need scanning will be easy. However, as you start to bring IPv6 inward to your organization, that list of IPv6 addresses will grow. You will need to anticipate this transition to dual-stack systems and have a strategy for how to gather up-to-date lists of IPv6 addresses and proactively perform vulnerability scanning.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/t5/IPv6-Center-of-Excellence/IPv6-Security-Vulnerability-Scanning/ba-p/7680.
Scott Hogg is the Chief Technical Officer (CTO) for GTRI.
