Weaponizing IPv6 to Bypass IPv4 Security

During the historic growth of the Internet in the 1990s - when venture capitalists funded anything with a .com at the end of the name and consumers rushed to experience a new center of knowledge - it quickly became clear that the mathematics behind IPv4 addresses needed to connect computers and devices would someday become obsolete. You may remember media drama, town halls, and inflammatory discussions over an imminent Internet address shortage.

Circa 1996, the Internet Engineering Task Force (IETF) took proactive steps to develop a successor to IPv4 in the form of IPv6. In stark contrast to the 4.3 billion addresses allowed by IPv4's 32-bit design, IPv6 theoretically delivers 7.9 x 10 to the 28th power more addresses. Although the Internet never came to a screeching halt as predicted, today's rapid rise of the Internet of Things (IoT) coupled with a year-over-year increase in Internet users has brought IPv6 back to the forefront. 

IPV6 Attack Vectors
As of last year, IPv6 has become an Internet standard, meaning that technology and processes are now in place allowing organizations to make a relatively smooth transition. As someone immersed in penetration testing and the ways cybercriminals can leverage technological change to their advantage, global IPv6 implementation at a varied pace piqued my curiosity. I proposed the theory that even organizations with a high degree of security maturity from an IPv4 standpoint, and that may not explicitly use IPv6, were still susceptible to IPv6 attack vectors because the protocol is now enabled by default on most modern systems and often overlooked by internal security teams. I decided to test this idea.

My team and I began by running a port scan on a Linux system IPv4 address that was scanned from a host on the same physical network. Unlike IPv4, IPv6 operates IP at Layer 2 in the OSI model instead of using a separate protocol like the Address Resolution Protocol. Therefore, when an IPv6-enabled system is connected to a network, it will configure itself with a Layer 2 address in the fe80::10 address range based on its MAC address and will listen to the default IPv6 multicast addresses (fff02::/10) for routers that advertise their presence. One special multicast address is ff02::1, which is for all IPv6-capable nodes connected to the local network segment. If you "ping" to this address, every IPv6 machine on the local network should respond to it, even if IPv6 has not been explicitly configured.

Indeed, after sending a ping we found five IPv6 capable devices on the local network. We also saw a device with IPv6 address fe80::280:10ff:fe22:3866, which corresponded to a MAC address associated with the IPv4 address previously scanned. The next step was to perform a port scan of this IPv6 address to see what's listening.

What we found is that the same ports we saw from the IPv4 address port were open and they seemed to be running the exact same services. But while the IPv4 address filtered other ports, all unused ports on the IPv6 address showed up as closed, which means the system is actively rejecting connection attempts rather than ignoring them. Most operating systems will reject attempts to connect to unused ports, while most host and network-based firewalls are configured to ignore such attempts. Comparing rejected connection attempts versus silently ignored connection attempts often aids in initial reconnaissance for cybercriminals.

Hijack Traffic 
The key takeaway from this experiment is that when either IPv6 or IPv4 is set up for auto-configuration but no configuration servers are on the network, other attacks are possible by introducing rogue servers to answer configuration requests. Modern operating systems prefer IPv6 over legacy IPv4 and will use a rogue IPv6 connection by default if one is available. This allows an attacker to hijack traffic such as Domain Name System lookups, creating a potentially bad security problem. There are already tools widely available to exploit this type of configuration attack.

It would seem that the best way to guard against these types of IPv6 style attacks would be to disable IPv6 — however, this is not recommended for several reasons. Many newer applications will now fail to work correctly if IPv6 is disabled. Similarly, although your organization may not yet be using IPv6, it's only a matter of time before it becomes a requirement, as the address pool continues to shrink and hacks such as network address translation designed to take advantage of IPv4 shortages become more prevalent.

Instead of disabling IPv6, consider its presence and ensure that any security rules applied to IPv4 now are being replicated to IPv6 and monitored in the same ways. Consider deploying and using IPv6 (at least on small portions of the network) as soon as possible to gain valuable experience working with the protocol and learning its many nuances before finding yourself in a scramble-mode situation playing catch-up. Those well versed in enterprise IT can attest that rushed security is always the worst security.

Top industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Click for more information.

Related Content: