Bravo to Fernando Gont for getting out a great Internet Draft (soon-to-be RFC) on the Implementation Advice on IPv6 Router Advertisement (RA) Guard. This has been one of the open, gaping wounds in the side of IPv6 enterprise deployment for years. In fact, many of us in the IPv6 and IPv6 security fields love to use this vulnerability to demonstrate at conferences. It’s a really fun one, we get to destroy Windows 7 boxes. 😀
In fact, see one of those demonstrations here. World renowned ethical hacker, Sam Bowne (@sambowne on Twitter), has done this at a few conferences. The one below was at DEFCON19.
IPv6 RA attack at DEFCON19
[youtube]http://www.youtube.com/watch?v=1EAnjZqXK9E[/youtube]
Anyway, the IPv6 Router Advertisement problem as it exists today.
What’s an RA?
The nature of host to network communication is started by the router on the network sending what is called a Router Advertisement, or RA to listening hosts on the subnet. The RA contains very critical information that tells all those hosts in the subnet many things like:
Pretty handy stuff, right? We agree, however hosts like Windows XP, 2003, Vista, 7, and 2003 don’t set a limit on the amount of routers they like to listen to. Whereas in Linux and Mac they set their limit at right around 15. If there are more than 15 different RAs coming at them, they stop configuring the address and routes.
This is not the case with Windows, and that’s what the exploit in the awesome exploitation toolkit called flood_router6 inside The Hacker’s Choice IPv6 tool-kit (THC-IPv6) shows. Flood_router6 will basically pound the subnet with millions of RAs with different IPv6 source addresses with different IPv6 prefixes. In a matter of seconds, you can turn a fully functioning Windows machine into a brick.
IPv6 RA Guard
Well, Cisco tried to get a jump on this problem a few years ago by building IPv6 RA Guard on their switch line and later writing the RFC: RFC 6105, IPv6 Router Advertisement Guard. This was a great solution! Until… A few hackers out there who love to play with packet manipulation tools like Scapy got ahold of it. The evasion technique is really quite simple. Send the subnet that same IPv6 RA ICMPv6 message, but put it right behind a Destination Options Header, and then inside a Fragment Header. This fools everything in the middle. For all you packet-heads and fellow proppellor-heads, this is what the packet string looked like courtesy of Mr. Gont:
Once the destination recives this packet (as by design) it puts the packet back together and sees it as an IPv6 RA. However, Destination Options are not meant to be read by intermediate devices like firewalls and/or routers, and that is why the ease of evasion.
Well, that gets us to the solution. And actually it’s a very simple solution: inspect the packet, and follow it until there is a final payload like TCP, UDP or ICMPv6. How Gont puts it, 3 implementation steps:
- When trying to identify an ICMPv6 Router Advertisement message, follow the IPv6 header chain, enforcing a limit on the maximum number of Extension Headers that is allowed for each packet. If such limit is exceeded, block the packet.
- If the layer-2 device is unable to identify whether the packet is an ICMPv6 Router Advertisement message or not (i.e., the packet is a fragment, and the necessary information is missing), and the IPv6 Source Address of the packet is a link-local address or the unspecified address (::), block the packet.
- In all other cases, pass the packet as usual.
Did we Really Solve Anything?
By finding, exploiting and now fixing the problem we have fundamentally exposed the possible horror of IPv6 extension headers: IPv6 packets need to really be inspected. Intermediate devices along the way can no longer assume an IPv6 header with a Destination Options extension header is okie-dokey to pass. What about Hop-By-Hop Options? This could be our next global Internet worm if we all don’t collectively start paying attention to how are wonderful flexibility and extensibility has achieved.
So we solved one problem, but now the cyber security community needs to start figuring out now what’s next. What else could be exploited in these extension headers?
