Just over 20 years ago, RFC 1883 – ‘Internet Protocol, Version 6 (IPv6) Specification’ – was published. Since then, exhaustion of the IPv4 address space, and a subsequent migration to IPv6 connectivity has been predicted, heralded, and warned against repeatedly. The seemingly endless stream of warnings and proddings over the past decade to “migrate or else…” have proved unfounded for most organizations. Understandably, this causes many organizations to dismiss or ignore recurring questions about IPv6 adoption, migration, and management plans.
However, consider the following usage statistics:
- The latest data from Google show nearly 10% of all traffic accessing their services as native IPv6.
- NIST’s Advanced Network Technologies Division (ANDT) ongoing tracking of the U.S. federal government’s external deployment of IPv6 shows approximately 50% of all USG web and DNS services available via IPv6.
- According to Hurricane Electric Internet Services, over 58,000 of the most popular websites (Alexa Top 1 million), and 20% of all networks running BGP offer IPv6 services.
- Every Windows operating system since XP includes enabled-by-default IPv6 connectivity. Likewise in Mac OS X, since 10.3. Development for IPv6 support in the Linux kernel began in 1996, and many Linux distributions now prefer IPv6 connectivity over IPv4.
- Modern mobile devices are generally IPv6-enabled, and carriers including Verizon Wireless and T-Mobile USA report more than half of connections to “big five” Internet companies (Google, Facebook, Yahoo, LinkedIn and Akamai) occur over IPv6.
- As the “Internet of Things” (IoT) ecosystem continues to proliferate, analysts estimate between 30-50 billion connected devices by the year 2020. Due to inherent IPv4 address space limitations, and pain points of workarounds such as NAT, these devices will by and large connect via IPv6 and related protocols such as 6LoWPAN.
Given these data points, it seems that IPv6 has in fact “arrived” – albeit slowly, and mostly under the radar. Due in part to the largely transparent nature of the roll-out, many organizations have overlooked security considerations associated with such significant changes to a foundational Internet protocol. This post will touch on a few key security points relevant to the migration.
IPv6 In Real-World Environments
During a penetration test, one of the first techniques to gain “situational awareness” entails passively sniffing network traffic. Analysis of this traffic can provide many clues as to how the network is configured and managed, what infrastructure services are in place, and client and server systems – operating system versions, web browser types, proxy settings, etc. A recurring theme we encounter during internal network penetration tests is the presence of IPv6-enabled systems broadcasting DHCPv6, ICMPv6 Neighbor Solicitation, and Router Solicitation packets.
While this may seem like harmless “background noise” traffic for systems that primarily utilize well-managed IPv4 connections, long-publicized attacks have been improved upon to enable malicious actors on the local subnet to intercept traffic from these systems. This and similar IPv6-based attacks are roughly analogous to long-known IPv4 equivalents such as ARP spoofing and DHCP spoofing – favored attack techniques of penetration testers and real-world attackers alike.
In addition to LAN communications, we’ve observed VPN-like technologies to establish remote connections to internal networks designed to use IPv6 by default – such as Microsoft’s ‘DirectAccess’. This capability is built into Windows client and server operating systems beginning with Windows 7 and Server 2008 R2, respectively – and thus is fairly widespread. Keep in mind, this technology does not require end-to-end IPv6 infrastructure – the software takes advantage of built-in IPv6 “transition technologies” such as 6to4, Teredo, and IP-HTTPS, making it all the more seamless.
In the reverse direction, both researchers and real-world malware have utilized unmonitored outbound IPv6 connectivity to exfiltrate data from compromised internal systems and networks. These communications generally evade detection capabilities and leave behind minimal forensic evidence in most environments.
Similarly, mainstream offensive security tools now include IPv6 discovery, attack, and post-exploitation capabilities. Metasploit, for example, now includes 51 payloads that communicate strictly over IPv6.
Nmap offers several IPv6 capabilities, including discovery of IPv6-enabled hosts on a local subnet, while producing traffic that is generally considered innocuous.
Reliable tools and techniques to manage IPv4 networks and protect against attacks have been well-known for years. Details around IPv6 network management, attacks, protections, and detection are much less understood. In our experience, sufficient controls are generally not in place, and detection capabilities are either unavailable, not understood, or ignored.
None of the above should be taken to suggest that IPv6 is inherently less secure – but to encourage organizations to assess their current state, including management of IPv6 connectivity, and their ability to prevent and detect attacks. To understand your organization’s current level of preparedness, consider the following questions:
- What public-facing systems and services are accessible via IPv6? (don’t neglect hosted systems – many cloud providers support IPv6 by default)
- What internal systems have IPv6 connectivity enabled? Is infrastructure in place to support and manage this connectivity? What controls are in place to protect against attacks abusing the protocol?
- Is outbound IPv6 connectivity supported? If not officially supported, is it explicitly prohibited, via policy and/or technical controls? (keep in mind the prevalence and ease of various tunneling and encapsulationoptions)
- Is inbound IPv6 connectivity supported? (keep in mind technologies such as Microsoft DirectAccess)
- Do existing defensive technologies (such as firewalls, IDS/IPS, web proxy, etc.) have visibility into IPv6 traffic? Do network boundary devices apply access control rules to IPv6 connections?
- Are IPv6 detection capabilities enabled? (Note that, given the use of extension (chained) headers for IPv6 options, evasion opportunities abound. Most products are capable of handling such manipulations, but with additional processing power requirements – therefore, IPv6 detection is often disabled by default.)
- Are logging solutions able to process and store IPv6 data? Are queries and alerts configured to support IPv6?
- Are security personnel (whether in-house or MSSP analysts) trained to understand and act upon IPv6 activity?
If you are uncertain of some answers, there’s no time like the present to begin understanding the next generation Internet Protocol!