Traditional host discovery via network scanning won't work with IPv6, but alternative methods are available

IPv6 brings some welcome security and other features, but there are some 'gotchas' for IP professionals that may not be immediately apparent.

The next generation IPv6 protocol has been "coming soon" for the last decade and is finally nearing the point of necessity as IPv4 addresses get closer to exhaustion. Many hail it as the next great thing for security because of nifty features like native IPSec support.

But it will also bring challenges for security pros, namely in vulnerability scanning and penetration testing. With the addition of all of this new IP space afforded by IPv6, scanning each IP to determine which hosts are up, and then performing a vulnerability scan, would take years. Host discovery through traditional means of network scanning -- host by host and subnet by subnet -- will go away. Instead, new host discovery methods will need to be put in place to make vulnerability scanning more targeted.

Fortunately, there are several techniques that can be used based on existing hardware and software tools. With little to no extra cost, it's possible to determine which IPs are in use on the network without scanning. You can then feed the discovered IPs into the vulnerability scanner so the scanner can spend more time on vulnerability scanning, and not on host discovery.

When looking for other hosts on the local network segment, IPv4's ARP was the usual method, but it's going away with IPv6. ARP's functionality is being replaced by IPv6's new Neighbor Discovery Protocol (NDP) within ICMPv6. There are several different functions in NDP, but in relation to host discovery, it can be used to discover other IPv6 hosts on the local network segment.

The limitation with NDP is it only finds hosts on the local network segment, which is great if you have a flat network. But in large, geographically diverse enterprises, it doesn't work across routers. To work around the problem segmented networks pose, you can issue those commands through a host on each network segment, or from a router with access to each segment.

From a penetration testing perspective, NDP can be used once access is gained into the network through physical access or compromise of an internal host. Attackers can leverage NDP to start finding other juicy targets to compromise that could provide deeper penetration into the network.

Network flow data is a commonly overlooked source of valuable information in a network. It provides a record of all network traffic on the network without recording the content. Most business-class and practically all enterprise-class routers and layer 3 switches support exporting network flow data. Using network flow records, it is easy to identify all hosts that have been communicating on the network during any given time period.

Armed with the hosts enumerated through network flow data, vulnerability scanning can commence and target only those hosts that are communicating during the last hour.

Some commercial vulnerability scanning and vulnerability management solutions such as Tenable's Security Center already have features to scan known hosts and new hosts as they are seen for the first time. Similarly, most network behavioral analysis products use network flow data and can initiate a vulnerability scan of hosts seen for the first time or acting outside of their normal baseline of behavior.

IPv6 IP addresses also are going to cause the Domain Name System (DNS) to become increasingly important, as IP addresses become nearly impossible to remember. In Microsoft Active Directory domains, DNS records are updating dynamically, so hostnames can be provided to a scanner instead of a list of IPs.

Interrogating DNS services using tools like Fierce will also become essential for penetration testers outside the network who don't have access to NDP and network flow data.

The Dynamic Host Configuration Protocol (DHCP) will also serve as a good source of host information for those networks using DHCPv6 to allocate site-local IP addresses to their internal hosts. DHCP server logs can be queried to see which IPs have been allocated, and to limit scans to only those IPs.

Systems and network administrators who are holding off as long as possible to deploy IPv6 are sticking their heads in the sand and ignoring the reality that IPv6 is already on their network. The inclusion of a fully functional IPv6 network stack in all modern operating systems including Windows, Mac OS X, and Linux means that even though IPv6 may not be routed across the network and Internet gateway, it can still be used for attacks on local network segments.

Penetration testers have realized this for several years, and tools like the Metasploit Framework have supported IPv6 since 2008. Once a host is compromised, IPv6 can be used to connect and exploit other systems on the local network segment. The root causes: host-based firewalls may not support IPv6, or the systems administrators didn't realize services often will listen on IPv4 and IPv6 and they only bothered to lock down the IPv4 side.

Intrusion detection and prevention systems (IDS/IPS) may also be leaving security teams blind to internal attacks carried over IPv6. Commercial and open source IDS and IPS solutions are adding support for IPv6 but it doesn’t exist across the board yet. Snort, for example, is an open source IDS on which many commercial products are based and it includes support for IPv6. But support is not enabled by default, and many of the available reporting tools do not support IPv6.

Whether you think you're running IPv6 or not, it's time to prepare for the impact it will have on your security efforts now and in the near future. Vulnerability management efforts will need to adapt, and hardening of hosts will require ensuring that both IPv4 and IPv6 are both locked down.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Published: 2015-03-31The build_index_from_tree function in index.py in Dulwich before 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.