IPV6 Under the Hood

Uploaded on

IPV6: Under the Hood - Mark Dowd

IPV6: Under the Hood - Mark Dowd

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • It can't be downloaded. The knowledge when shared it's multiplied instead of divided. Share knowledge. Bad done
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. IPv6: Under The Hood Mark Dowd Principal Security Architect [email_address]
  • 2. Overview
    • IP version 4 (IPv4) is a core component of the Internet’s TCP/IP suite
    • Time-tested, well-understood and extensively studied protocol
    • Has some shortcomings when addressing the changing needs of the Internet (limited address space, security issues, functionality limitations, and inefficiencies)
    • IP version 6 (IPv6) is IPv4’s successor, and attempts to address these shortcomings
  • 3. Why IPv6?
    • IPv6 is the next-generation Internet workhorse-protocol
    • Many OS’s have IPv6 support (Linux, Windows XP2+/2k3/Vista, *BSD..)
    • IPv4 protocol stacks are time-tested and proven to work in untrusted and uncertain environments, IPv6 stacks are not
    • Many OS’s have fresh stacks that are ripe for the hacking
    • Same with firewall-based technologies targeted for IPv6
    • IPv6 connectivity over the Internet is increasingly being made available
  • 4. Covered in this Speech
    • We will look at some of the basic building blocks of IPv6
    • We will consider some of the inherent weaknesses in some of the IPv6 protocol design
    • Problem areas in host OS stack implementations
    • Firewall/IDS/IPS bypassing techniques
  • 5. IPv6 Addressing
    • IPv6 Addresses are 128-bit
    • Represented as 16-bit words separated by colons (‘:’)
    • Example: 0102:0304:0506:0708:090a:0b0c:0d0e:0f00
    • Sequences of zeros compressed using “::”
    • Example: 0102:0000:0000:0000:090a:0b0c:0d0e:0f00 -> 0102::090a:0b0c:0d0e:0f00
  • 6. IPv6 Addressing
    • Link-local addresses (fe80::/64) are only visible on a local physical link
    • Every IPv6-enabled network interface must have a link local address
    • Usually an interface will auto-configure its link-local address when it is enabled (more on this later)
    • Site-local addresses (fec0::/10) are for internal networks
    • Much like 192.168 and similar ranges for IPv4
  • 7. IPv6 Addressing
    • Unique local addresses (FC00::/7) are unique network ranges within an organization
    • Global Unicast addresses (2000::/3) are public routable IP addresses
    • IPv6 has multicast addresses for sending packets to groups of nodes simultaneously. Multicasting is also used for broadcasts
    • There are also anycast addresses, which is like multicast except that a packet will be delivered to any one node in the group (the closest node)
  • 8. IPv6 Packet Structure
    • An IPv6 packet is composed of an IP header, followed by any number of optional extension headers, followed by an Upper-Layer (UL) protocol header + data
    • Each optional header can be from 8 bytes in length up to 2048 (1 byte length header is incremented and multiplied by 8)
    • There are a few fixed-length ones that don’t follow these rules (primarily the fragmentation header)
  • 9. IPv6 Packet Structure
  • 10. IPv6 Packet Structure
  • 11. IPv6 Extension Headers
    • Hop-by-Hop Header if present, is always first
    • Comprises a series of options that are processed by each routing hop
    • Has TLV-based options including router alerts (RSVP) and jumbo payload size for large packets
  • 12. IPv6 Extension Headers
    • Destination Options Header
    • Also has a series of TLV options, but they’re just processed by the destination, not intermediate routers
    • Fragmentation Header for fragmented packets (discussed later)
    • Routing Header – basically the IPv6 equivalent of source routing (we will look at this again later too)
    • AH/ESP Headers – for encrypted communications
    • IPv6 Headers – encapsulation
  • 13. IPv6 Fragmentation
    • IPv4 stacks and firewalls experienced a myriad of problems related to fragmentation
    • Since fragmentation is the basis of some of the attacks we will look at with IPv6 as well, the process is explained here
    • IP packets can have a series of option headers (the “non-fragmentable” part) followed by a fragment header, followed by fragmented data (“fragmentable part”)
  • 14. IPv6 Fragmentation (expected traffic)
  • 15. IPv6 Fragmentation (allowable traffic)
  • 16. Address Discovery
    • Local nodes can auto-configure themselves on a network to some extent
    • This is achieved with ICMPv6 Neighbour Advert/Solicitation requests
    • Replaces ARP
    • There are also related “Router Advertisement” / “Router Solicitation” exchanges to establish MTU’s, TTL’s, and more
  • 17. Address Discovery
    • This stuff isn’t performed with any level of authentication
    • Possible to do similar attacks to “ARP Spoofing” that was popular with IPv4
    • Originally demonstrated by “Van Hauser” from THC (http://thc.segfault.net/releases.php)
  • 18. OS Stacks
    • Many OS’s now have IPv6 stacks
    • There are a number of problem areas that can be easy to get wrong
    • Focusing on these areas is a good place to start when conducting an audit of an IPv6 stack
  • 19. OS Stacks - Basic Header Parsing
    • In general, length manipulations are safer than in IPv4
    • Length values for the IPv6 header and options headers never include the length of the header itself, so no math needs to be done on an untrusted length value
    • Less likely to have integer underflows
    • Special case: When length is 0 in the IPv6 header, a Hop-by-Hop header must follow with a Jumbogram options
    • What happens when a length exists in the IP header and a jumbogram option is supplied?
    • What about if there is no jumbogram option and the IP header length is 0?
  • 20. OS Stacks - Basic Header Parsing
    • Optional headers of course need their length verified to ensure that they don’t specify a length larger than the packet
    • Failure to do so would result in potential kernel panics or memory corruption
    • TLV parsing within Destination options and Hop-by-Hop options can also skip out of bounds if careful checks aren’t in place
    • This is possible on BSD, although it doesn’t seem to buy you anything (maybe an interesting evasion technique)
  • 21. OS Stacks – Error Generation
    • A number of checks are needed to ensure generated errors can’t create smurf-like scenarios
    • Destination should not be multicast
    • Source should not be multicast
    • IPv4 mapped addresses are also dangerous, exposing potential IPv4 multicast/broadcast addresses
  • 22. OS Stacks - Routing
    • Usually a host has to be configured to forward packets to perform the routing specified in the packet
    • Many special cases they need to be careful of
    • Multicast Destinations
    • Multicast Next Hops
    • IPv4-mapped Destinations
    • IPv4-mapped Next Hops
    • Link-local or site-local hops
    • Globally-unique local hops
  • 23. OS Stacks - Fragmentation
    • Fragmentation is interesting for a few reasons – errors in implementation, fingerprinting, and firewall/IDS de-synchronization
    • IPv4 stacks had a few major vulnerabilities due to incorrect reassembly
    • Errors in fragmentation either result in memory corruption, out of bounds kernel reads, mistakenly thinking fragments are complete and passing it to a higher layer, or accidentally including auxilary data
  • 24. OS Stacks – Fragmentation Quirks
    • Fragmentation also exposes unique behaviour of the OS
    • Windows will discard fragment queues if overlaps are found in most cases
    • BSD will discard an overlapped fragment, but keep the queue
    • Linux allows overlaps using the same algorithm as its IPv4 stack (favors earlier fragments)
    • Timeouts and thresholds will also differ
  • 25. Firewalling
    • IPv6 is a good target to undermine firewall rulesets
    • Simple packet filtering through to more complex state mechanisms
    • For packet filtering: want to block certain upper-layer protocols, extension headers, or more specific information (certain ports, or properties within extension headers)
  • 26. Firewalling – Packet Filtering
    • Extension Headers are desirable to filter
    • Things like routing extensions can be particularly useful in violating policy
    • Filtering packets containing them should be fairly easy, but there are some tricks to it
    • Based around handling fragmented packets
  • 27. Firewalling – Packet Filtering
    • One method we can employ is the “NUL fragment” technique
    • Set the offset to 0 and the MF bit also clear
    • OS stacks will all ignore this header and continue regular processing
    • Some packet filters will try to record it for reassembly and so forth
    • Linux IP’s conntrack netfilter module does this
  • 28. Firewalling – Packet Filtering
    • Otherwise, we can just fragment a datagram with a series of optional headers following
    • Put the optional header being filtered in a non 0-offset fragment
  • 29. Firewalling – Packet Filtering
    • Most packet filters only check the first (0-offset fragment)
    • For good reason – processing other datagrams is wrong because the data in the fragment might not even be options
    • The only way to detect extensions in these fragments is to reassemble the datagram first
    • Filters attempting to detect payloads in non-0 offset fragments are trivially bypassed
  • 30. Firewalling – Packet Filtering
    • What about upper layer protocols (TCP/UDP/ICMP/others) ?
    • We can do the same thing in some cases
    • Filling the first fragment with just extension headers make it hard for the packet filter to figure out what kind of data is in the packet
    • Dealing with non 0-offset packets is easy to get wrong – really can’t rely on anything after fragment header
  • 31. Firewalling – Packet Filtering
    • Why? Again, it might be halfway through another option or some data
    • Result: Parsing data as extension headers when they’re not
    • “Next Header” value in non 0-offset fragment is ultimately ignored
    • IPTables/IP6Fw actually pays attention to this next header to figure out upper-layer protocols, so you can match on pretty much arbitrary rules
  • 32. Firewalling – Packet Filtering
    • Fragmentation is a good way of desynchronizing a firewall or IDS
    • Using this technique, we make the firewall/packet filter see a different kind of packet than the end host
    • Result: incorrect match which could allow packets through that are meant to be blocked
    • Exploit variances in how the firewall reassembles packets and how the end host does
  • 33. Firewalling – Duplicate Fragment Sets
    • Duplicate Fragment Sets is sending two sets of fragments, both of which assemble and can pass a firewall inspection
    • Both fragment sets have the same ID field
    • We then want to have select fragments dropped from each assembled fragment set to create a new assembled packet that shouldn’t have been allowed
  • 34. Firewalling – Duplicate Fragment Sets
  • 35. Firewalling – Duplicate Fragment Sets
    • How do we drop select fragments?
    • In IPv4 it was possible setting the TTL on some packets to a low value so they would expire after the firewall but before the end host
    • Thomas Lopatic used an inventive technique involving abuse of the timestamp IP option
    • In IPv6, it’s much easier because there are a lot of ways to invalidate a packet, especially if they’re not examined particularly closely by a firewall
  • 36. Firewalling – Packet Invalidation
    • Low TTL – easy technique but probably will be detected
    • Destination Option TLV’s can be used to force the host to drop fragments (as can HBH ones, but each hop will pick those up…)
    • Invalid routing options – not a 0-type route or has a multicast destination
    • Valid routing options that have multiple entries to deliver to the same host or router just before the end host, thus eating up TTL’s
    • Timing attacks
  • 37. Firewalling – Packet Invalidation
    • Sometimes packet filters/firewalls will let you have unknown headers too, whereas the end host will drop them
    • Firewalls/filters also often will allow you to put hop by hop option headers anywhere, whereas end hosts don’t
    • Insert a HBH option somewhere in the middle of the packet and it will never make it through processing
  • 38. Firewalling – Fragment Stacking
    • Fragment stacking is a technique where you put multiple fragment headers inside a single datagram
    • Alternatively, you have a fragment header somewhere inside a fragmented packet
    • When the packet is reassembled, the newly formed packet is still a fragment of another chain!
    • You can nest fragment headers arbitrarily deep
  • 39. Firewalling – Fragment Stacking
  • 40. Firewalling – Fragment Stacking
    • Useful for messing with firewalls trying to reconstruct the packet stream
    • Firewalls packet filters record information about either the first fragment header they see, or the last one
    • This can lead to them making inaccurate decisions about what the packet really contains
    • Also useful for firewalls attempting to cache ID’s to prevent duplicate fragment set attacks
  • 41. Firewalling – Stateful Inspection
    • Stateful inspection firewalls are generally harder than packet filters
    • Fragment duplication and stacking can help to bypass them
    • Another thing they need to be careful of is TCP/UDP header processing
    • Some firewalls will inspect flags of a TCP packet to decide whether a connection is open or not
  • 42. Firewalling – Stateful Inspection
    • A trick here was to send an overlapping fragment at offset 1 in a TCP packet, overwriting the flags portion of the header
    • Lot’s of implementations check for this, even in IPv6
    • That particular check is not useful in IPv6 though, because the TCP header doesn’t need to start at offset 0
    • We can pad with extension headers, thus causing it to check potentially invalid flags
    • Pretty hard to pull off still though, due to the way most hosts to fragmentation
  • 43. Firewalling – Stateful Inspection
    • We can also supply TCP or UDP packets that are not going to ever get to the host
    • This might be useful if we want the firewall to maintain or teardown a connection entry
    • We can use the techniques for invalidating packets described earlier
    • TTL’s, routing headers, invalid destinations, and so on
  • 44. Firewalling – Stateful Inspection
    • Routing Headers might also provide some interesting possibilities
    • What if we route the packet around to a less protected interface on a target host?
    • Maybe we can use this to elicit some sort of response due to misplaced trust
    • Windows XP firewall seems to exhibit some behavior like this
    • What if we could entice a host/router to send a packet that was originated by us back to us?
    • Using the routing header with the attacking host as one of the hops can be used to accomplish this
  • 45. Firewalling – Stateful Inspection
  • 46. Firewalling – Stateful Inspection
  • 47. Firewalling – Stateful Inspection
    • Let’s say we wanted to contact a target machine on port 22, but the firewall only lets in port 80
    • It has TCP connection awareness
    • We send a packet (src port: 22, dest port: 80) with their IP as a source address and destination
    • They get it, inspect the routing header and send it back
    • Should redirect in this case really, but at least Windows and BSD seem to route wherever you want (Linux will send a redirect)
  • 48. Firewalling – Stateful Inspection
    • Firewall sees packet (source port: 22, dest port: 80) and makes a new connection entry
    • We now have the possibility of contacting the target on port 22
    • Potential problems: careful flags checks might detect something is up
    • Anti-spoofing will see source and destination address the same, or at least source address not valid for receiving interface
    • Tunneling can come in handy here
  • 49. Tunneling Data
    • Tunneling is a big issue in IPv6, especially for nodes that do both IPv4 and IPv6
    • IPv6 over IPv4
    • IPv4 over IPv6
    • IPv6 over IPv6 (supported by default on Windows)
    • Arbitrary levels of nesting
    • Combined with fragmentation tricks, firewalls have their work cut out for them
  • 50. Tunneling Data
    • Tunneling to hosts has several uses
    • Bypassing firewall rules
    • Contacting hosts behind a firewall using routing combined with tunneling
    • Contacting non-routable (link-local/site-local) addresses using routing headers
    • Additional bonus that your tunneled IP data is not going to be subject to anti-spoofing and other validation in many cases
    • Special Address Classes are also useful – we could route over to their IPv4 accessible network for example
  • 51. Questions?
    • Any Questions?