Mitigating IPv6 Poisoning Attacks

As an increasing number of companies support both IPv6 and IPv4 protocols, our team is finding a common misconception that since IPv6 is newer, it is also safer. Sadly, this is not necessarily the case. This blog will review the differences between IPv4 and IPv6, the cybersecurity implications of these protocols, and how to mitigate IPv6 poisoning attacks.

What are IPv4 and IPv6?

Internet Protocol version 4 (IPv4) is a very well-known mechanism used in the addressing and routing of networked systems. IPv4 uses 32-bit addresses (2³²) and allows for a total of just under 4.3 billion addresses, which seems like a lot, but that number has quickly been allocated. IPv6 was developed more than 20 years ago to address the dwindling number of available IPv4 addresses. IPv6 uses a much larger address space (2¹²⁸) and should provide address availability for the foreseeable future.

What are the Pros and Cons of IPv6 vs IPv4?

The benefit of IPv6 is obvious when considering the scale of the Internet. However, IPv4 is still ubiquitous when it comes to almost any other network, likely including your organization’s Local Area Network, your home network, and even the networks of the largest global enterprises. IPv4’s 2³² address space is plenty large enough for those networks and has the major benefit of being easier to work with as it has been the standard in IT for nearly 40 years.

IPv4 is still the primary addressing mechanism used in modern networks, but that does not mean that IPv6 is not used at all. Current networking devices and operating systems will run both protocols and often do so by default. Because of this, we commonly find IPv6 enabled and running right alongside IPv4, and often exhibiting the same vulnerabilities that are well-known in the IPv4 protocol.

The Cybersecurity Implications of IPv4 and IPv6

When we wrote about the top internal network security risks back in 2019, we touched on both broadcast and name resolution protocols. We still see these in use frequently during internal penetration tests, though mitigations are better documented and generally password practices continue to improve. Password strength is important here because often when we’re exploiting these vulnerable protocols, we’re receiving hashed credentials that then need to be cracked. (Alternatively, relaying attacks can be performed, but that is a topic for another blog post.)

What is hash cracking? Hash cracking is the process of determining the original cleartext string to which a hashing algorithm has been applied. The result is similar to decryption, however with hash cracking the encryption key is not known so the ciphertext can’t simply be “reversed.” Stronger passwords are usually more difficult to crack, though poor password practices still exist in 2021.

We see these vulnerable broadcast protocols more rarely as the years have passed, however there are similar vulnerabilities in IPv6, specifically with Router Advertisements, DHCP, and DNS. Recently, folks have become more aware of broadcast poisoning because of the Internet Control Message Protocol (ICMP) vulnerability known as “Bad Neighbor” that could result in Remote Code Execution (RCE). This vulnerability specifically affected IPv6 Router Advertisements, but IPv6 can facilitate other nefarious things too.

A favorite technique of our pentest and red team testers is poisoning DNS via IPv6 DHCP requests, which we can then leverage to collect hashed user credentials or perform relay attacks in the same manner that we could in IPv4 with NetBIOS Name Service (NBNS), Link-Local Multicast Name Resolution (LLMNR), or multicast Domain Name System (mDNS).

Responder is a very effective tool for poisoning these IPv4 broadcast protocols and is commonly used within the penetration testing community. Steps for mitigating NBNS and LLMNR poisoning are well documented elsewhere.

However, these documented mitigations don’t address DNS poisoning via IPv6 DHCP requests. When performing this attack, we use mitm6 from Fox-IT, who wrote a great blog post on exploiting this attack vector. This attack is based on the fact that in unconfigured IPv6 networks, Windows clients will send DHCPv6 configuration requests, which will be favored over whatever has been configured via IPv4. By responding to these DHCPv6 configuration requests attackers are able to specify the DNS server to be used by the client, which enables the attacker to redirect traffic to the destination of their choosing. As pentesters, we can leverage this behavior to collect hashed user credentials or perform relay attacks with Impacket’s ntlmrelayx.py.

As these attacks are based on DHCPv6 configuration requests, we can effectively mitigate them by preventing the configuration requests from being sent in the first place. The following PowerShell script first queries network interfaces on the local host that support IPv6, then for each, it toggles Router Discovery and DHCP to “Disabled.”

This script can be run locally to harden individual hosts or could easily be deployed through Group Policy or other endpoint management tools, such as System Center Configuration Manager. As always, configuration changes such as these should be thoroughly tested in your organization’s unique environment, and previous configurations should be backed up before the updated configurations are deployed to production systems.

Remember, just because IPv6 is newer, doesn’t mean it is more secure. It was built to expand the address space of the Internet Protocol, not as a security patch. Security staff must continue to be vigilant in understanding what protocols are running in their environment, what vulnerabilities exist, and what steps to take to reduce the risk of exploitation.

We hope this information has been helpful. Please contact us if you need help with technical testing, advisory or compliance services, incident response or technical training.