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: Attack Tools: 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? 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: Configuring a policy for Neighbor Discovery (ND) can defend against the IPv6 reconnassance tools: int Ethernet x/y 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 578 Posts ISC Handler Sep 13th 2017 |
Thread locked Subscribe |
Sep 13th 2017 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!