SANS ISC: No IPv6? Challenge Accepted! (Part 1) - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

I recently had an internal penetration test with a client.  During the initial discussions, where the client set the scope and so on, I asked if they had any IPv6 in their environment (mainly because I'm hoping that someday, someone will say yes).  Their answer was an emphatic "no".  My answer to that was "Challenge Accepted?", and they ruled IPv6 in scope with a "knock yourself out, there's nothing there".

As many of you know, IPv6 is enabled on most modern operating systems, and if a path is found, IPv6 is usually prefered over IPv4.  In most organizations though, IPv6 is disabled on the routers and firewalls - so there's nowhere for IPv6 to go and no way for IPv6 to be auto-configured (aside from Locally Administered Addressing).  That is, until there's a malicious actor (that'd be me) in the environment.

You don't have to look far for tools to exploit the IPv6 protocol.  Kali has the most excellent THC IPv6 Attack Toolkit installed (https://github.com/vanhauser-thc/thc-ipv6).  Using this toolkit is pretty straigtforward (I only list the tools I commonly use below):

Enumeration Tools:
alive6 is a quick and dirty "what IPv6 hosts are on my network segement?" tool
dump_router6  will (as you'd expect) dump any IPv6 routers on the local segment.  In a production environment, "netstat -rn" will usually do the trick also.
passive_discovery6 combines a number of features, doing passive discovery of the entire network segment, and lifting all the information from the IPv6 multicast packets (which is used instead of broadcasts like ARP in IPv6).

Attack Tools:
fake_dhcps6 and fake_dns6d stand up malicious DHCP and DNS servers, which allow you to give victim hosts "real" IPv6 addresses that can be routed, and resolve DNS queries to malicious IPv6 host addresses.
fake_router26 and fake_router6 are the "go to" Man in the Middle attack tools for IPv6 - these allow you to stand up a default router for IPv6, which will be prefered over existing IPv4 routers.  Note that you need to set up a mechanism to forward IPv6 packets.  This means you need to enable IPv6 forwarding, then either tunnel IPv6 outbound, usually to an internet gateway, or nat/proxy the IPv6 packets back to IPv4 (which you then forward to the "real" IPv4 router).  What this means is that there's some thought and preparation required to mount this attack.  

Mounting an IPv6 Man in the Middle attack is as simple as: "fake_router6 eth0  BAD1::00/64" (the last parameter is the network - either your "fake" IPv6 network, or your customer's real IPv6 network).  Note that you then have to do the other half - send the victim stations' packets on to their destination (stay tuned for that in my next post).

kill_router6 allows you to take any production IPv6 router offline.  So far I haven't needed this tool, IPv6 just isn't widely implemented in corporate clients I generally work with.

More info on using the THC attack toolkit can be found here: https://tools.kali.org/information-gathering/thc-ipv6

Defenses against these attacks?
The defenses against IPv6 router hijack attacks lie primarily in an organization's switches.  Enabling a feature called "RA Guard" to simply block Router Advertisements (defending against the fake router attack tools):
int Ethernet x/y
    ipv6 nd raguard

If you don't have an IPS on every segment, enabling RA guard on switches will create a syslog event - you can monitor for that with your SEIM, or even easier, look for it directly on your syslog server ( https://isc.sans.edu/forums/diary/Syslog+Skeet+Shooting+Targetting+Real+Problems+in+Event+Logs/19449/ ) .  The log entry you are looking for is:
"ICMPv6-ND: Received RA from FE80::1 on Vlan72"  (of course the vlan number will vary)

Configuring a policy for Neighbor Discovery (ND) can defend against the IPv6 reconnassance tools:
ipv6 nd inspection policy NDPOLICY
    drop-unsecure
    sec-level minimum 2
    device-role monitor

int Ethernet x/y
    ipv6 nd inspection attach-policy NDPOLICY vlan add all

Then don't configure any "trusted" ports for RA (Router Advertisements)

Of course, on any segment that you have an IPS sensor you can use that too, if you don't have IPv6 running in production then if you detect any IPv6 RA packets, DNS responses from a local IP or a DHCP6 responses, these should all be classified as attacks, and dealt with some sense of priority.

Cisco covers IPv6 First Hop Security in much more detail here: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book/ip6-snooping.pdf - I'd recommend looking at encryption and signing of the IPv6 infrastructure functions if you're standing up an IPv6 infrastructure, and not just defending against rogue IPv6 in an IPv4 network.

Stay tuned, in the next installments to this story I'll cover some handy IPv6 NAT/Proxy attack techniques, a soup-to-nuts IPv6 based Man in the Middle attack, as well as defenses you can implement on on firewalls.

Have I missed anything important in this post?  Do you use a different set of tools to attack IPv6 - maybe Scapy or Metasploit?  Please, post your tools or approaches for discussion in our comment form

===============
Rob VandenBrink
Compugen