IPv6 MITM via fake router advertisements

Published: 2011-04-05
Last Updated: 2011-04-05 18:52:01 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

A recent article [1] describes a rather neat variation on how fake router advertisements can be used with IPv6 capable hosts to intercept traffic, including tricking hosts to use IPv6 to connect to systems that normally are not reachable via IPv6.

First lets start with the "old" part of this attack: Fake router advertisements. IPv6 relies a lot more on auto configuration then IPv4. While techniques like "zero configuration" can be used in IPv4, we usually find DHCP used to configure IPv4 networks. In IPv6, routers are typically used to configure a network via "router advertisements". A router advertises which network it is willing to route, and hosts connected to the router will pick an address within this network. 

In short, router advertisements can be considered a "DHCP lite" for IPv6. If I introduce a fake router, I get the same effect as I would get from a fake DHCP server in IPv4. However, as only few networks implement IPv6, a fake IPv6 router is likely to be the only IPv6 router. Hosts which so far had no connectivity to the IPv6 internet will now use this fake router to connect. Fake router advertisement tools are very common, we actually play with one in my IPv6 class (fake_router6 from the THC kit) 

Big deal. There are not a lot of IPv6 sites. So why should I care? The reason you may need to care is a protocol called "NAT-PT". NAT-PT is an experimental protocol used to connect IPv6 only networks to the legacy IPv4 network. NAT-PT works by returning IPv6 addresses for DNS lookups that would otherwise only return IPv4 addresses. Once a host connects to this "mapped" IPv6 address, the NAT-PT router will translate the IPv6 connection to an IPv4 connection, much like we are used to from IPv4-to-IPv4 NAT.

By combining the fake RA advertisements with NAT-PT, the attacker has the ability to intercept traffic that would normally use IPv4. To make things more interesting, if a host has IPv6 and IPv4 connectivity, the IPv6 connection is preferred, causing this attack to work even better.

What are the work arounds? How do you defend?

- IPv6 is a wonderful protocol. But if you don't need it: Turn it off. If you need it, then monitor and defend it like IPv4
- the attack does require layer 2 access. Physical access to your network should be restricted
- if you use an "open" network (e.g. public wifi), use encryption to protect yourself (SSL, IPSec). This attack is not more deadly in this case then other layer 2 attacks.

[1] http://resources.infosecinstitute.com/slaac-attack/

 And also see our IPv6 Security Summit in July

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: ipv6 mitm
6 comment(s)


"the attack does require layer 2 access. Physical access to your network should be restricted"

This gives the attack the same profile as other L2 attacks... such as ARP poisoning; hijacking through CAM flooding and MAC address spoofing.

"IPv6 is a wonderful protocol. But if you don't need it: Turn it off. If you need it, then monitor and defend it like IPv4"

Most networks don't have Layer 2 defenses for IPv4; in that case there is no security benefit from "turning off" the IPv6 function, because the threat is just a duplicate.

The IPv4 weaknesses are more likely to be used, exactly as severe, and harder to detect than use of the IPv6 weakness.

MAC address spoofing is basically "invisible" to an IDS, only managed switches can help, but rogue announcements to a multicast address are highly detectable.

If you don't "need" IPv6 right now; you will need it very soon -- now is the time to be securing it and making certain everything work with it, not the time to turn it off.

IPv6 SEND/ rfc3971 secure neighbor discovery is a more secure option than anything in the IPv4 protocols....
As a colleague of mine pointed out, isn't this dependent on a switching/routing infrastructure that forwards and routes IPv6? If your (Layer 3) core switches do not route IPv6, then the attack should only work for a small local segment of an IPv4 network, right?
The fake router would implement a tunnel to route IPv6 over IPv4. This attack is in particular likely to succeed if there is no IPv6 routing infrastructure in the network as the fake router doesn't have to compete with real routers.
Regarding IPv6 SEND: great protocol and a nice defense against this, but sadly not widely implemented (only Windows 7 and Windows 2008 R2 implements it).
Note: NAT-PT has been deemed deprecated by IETF because of its tight coupling with Domain Name System (DNS) and its general limitations in translation, and it has proven as technology to be too complex to maintain scalable translational services. With the deprecation of NAT-PT and the increasing IPv6 transition among users has led to the introduction of NAT64. 

From ietf Institute it clearly states that this has been deprecated. In addition to that I think the writer has the the implementation of IPv6 backwards it should be that ipv4 if you don't need it only in certain instances should be turned off. IPv6 is a ubiquitous protocol which has security mechanisms that are built in, meaning that encapsulated secured payload and authenticated headers are part of the protocol. The writer forgot to mention that particular part in addition to that there is ipsec AES 256-bit encryption that is part of its existing stack. Ipv4 does not offer any of these you have to purchase Hardware in order to get this level of functionality. So yes nothing is perfect and IPv6 is one of those protocols that is not perfect however I rather have IPv6 as part of my backbone, then I can really start routing traffic and manipulating that is secure to the end user.

Also I was thinking a way to filter specific traffic inside the network would be to include ACLs at the router and switch level where they only allow traffic for a particular prefix. Then it would be easy to identify the traffic that is not part of your existing environment, in addition in most instances if a person has physical access to the network then you're security mechanisms have already been compromised.

Not sure you noticed. But this post is 7 years old :)

Diary Archives