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:
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.
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.
-- CODE lang-shell --$ cat /tmp/payloads.txt | grep -i ipv6
bsd/x64/shell_bind_ipv6_tcp
bsd/x64/shell_reverse_ipv6_tcp
bsd/x86/shell/bind_ipv6_tcp
bsd/x86/shell/reverse_ipv6_tcp
bsd/x86/shell_bind_tcp_ipv6
bsd/x86/shell_reverse_tcp_ipv6
cmd/unix/bind_netcat_gaping_ipv6
cmd/unix/bind_perl_ipv6
cmd/unix/bind_ruby_ipv6
cmd/windows/bind_perl_ipv6
linux/x86/meterpreter/bind_ipv6_tcp
linux/x86/meterpreter/bind_ipv6_tcp_uuid
linux/x86/meterpreter/reverse_ipv6_tcp
linux/x86/shell/bind_ipv6_tcp
linux/x86/shell/bind_ipv6_tcp_uuid
linux/x86/shell/reverse_ipv6_tcp
linux/x86/shell_bind_ipv6_tcp
php/bind_perl_ipv6
php/bind_php_ipv6
php/meterpreter/bind_tcp_ipv6
php/meterpreter/bind_tcp_ipv6_uuid
ruby/shell_bind_tcp_ipv6
windows/dllinject/bind_ipv6_tcp
windows/dllinject/bind_ipv6_tcp_uuid
windows/dllinject/reverse_ipv6_tcp
windows/meterpreter/bind_ipv6_tcp
windows/meterpreter/bind_ipv6_tcp_uuid
windows/meterpreter/reverse_ipv6_tcp
windows/meterpreter_reverse_ipv6_tcp
windows/patchupdllinject/bind_ipv6_tcp
windows/patchupdllinject/bind_ipv6_tcp_uuid
windows/patchupdllinject/reverse_ipv6_tcp
windows/patchupmeterpreter/bind_ipv6_tcp
windows/patchupmeterpreter/bind_ipv6_tcp_uuid
windows/patchupmeterpreter/reverse_ipv6_tcp
windows/shell/bind_ipv6_tcp
windows/shell/bind_ipv6_tcp_uuid
windows/shell/reverse_ipv6_tcp
windows/upexec/bind_ipv6_tcp
windows/upexec/bind_ipv6_tcp_uuid
windows/upexec/reverse_ipv6_tcp
windows/vncinject/bind_ipv6_tcp
windows/vncinject/bind_ipv6_tcp_uuid
windows/vncinject/reverse_ipv6_tcp
windows/x64/meterpreter/bind_ipv6_tcp
windows/x64/meterpreter/bind_ipv6_tcp_uuid
windows/x64/meterpreter_reverse_ipv6_tcp
windows/x64/shell/bind_ipv6_tcp
windows/x64/shell/bind_ipv6_tcp_uuid
windows/x64/vncinject/bind_ipv6_tcp
windows/x64/vncinject/bind_ipv6_tcp_uuid
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:
If you are uncertain of some answers, there’s no time like the present to begin understanding the next generation Internet Protocol!
