Title: IPv6: Under The Hood
1IPv6 Under The Hood
Mark Dowd Principal Security Architect mark_dowd_at_
mcafee.com
2Overview
- IP version 4 (IPv4) is a core component of the
Internets 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 IPv4s successor, and
attempts to address these shortcomings
3Why IPv6?
- IPv6 is the next-generation Internet
workhorse-protocol - Many OSs 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 OSs 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
4Covered 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
5IPv6 Addressing
- IPv6 Addresses are 128-bit
- Represented as 16-bit words separated by colons
() - Example 0102030405060708090a0b0c0d0e0f00
- Sequences of zeros compressed using
- Example 0102000000000000090a0b0c0d0e0f00
- 0102090a0b0c0d0e0f00
6IPv6 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
7IPv6 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)
8IPv6 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 dont
follow these rules (primarily the fragmentation
header)
9IPv6 Packet Structure
10IPv6 Packet Structure
11IPv6 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
12IPv6 Extension Headers
- Destination Options Header
- Also has a series of TLV options, but theyre
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
13IPv6 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)
14IPv6 Fragmentation (expected traffic)
15IPv6 Fragmentation (allowable traffic)
16Address 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
MTUs, TTLs, and more
17Address Discovery
- This stuff isnt 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)
18OS Stacks
- Many OSs 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
19OS 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?
20OS Stacks - Basic Header Parsing
- Optional headers of course need their length
verified to ensure that they dont 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 arent in place - This is possible on BSD, although it doesnt seem
to buy you anything (maybe an interesting evasion
technique)
21OS Stacks Error Generation
- A number of checks are needed to ensure generated
errors cant 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
22OS 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
23OS 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
24OS 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
25Firewalling
- 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)
26Firewalling 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
27Firewalling 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 IPs conntrack netfilter module does this
28Firewalling 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
29Firewalling 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
30Firewalling 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 cant rely on anything after
fragment header
31Firewalling Packet Filtering
- Why? Again, it might be halfway through another
option or some data - Result Parsing data as extension headers when
theyre 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
32Firewalling 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
33Firewalling 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 shouldnt have been allowed
34Firewalling Duplicate Fragment Sets
35Firewalling 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, its much easier because there are a lot
of ways to invalidate a packet, especially if
theyre not examined particularly closely by a
firewall
36Firewalling Packet Invalidation
- Low TTL easy technique but probably will be
detected - Destination Option TLVs 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 TTLs - Timing attacks
37Firewalling 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 dont - Insert a HBH option somewhere in the middle of
the packet and it will never make it through
processing
38Firewalling 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
39Firewalling Fragment Stacking
40Firewalling 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
IDs to prevent duplicate fragment set attacks
41Firewalling 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
42Firewalling 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 - Lots of implementations check for this, even in
IPv6 - That particular check is not useful in IPv6
though, because the TCP header doesnt 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
43Firewalling 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 - TTLs, routing headers, invalid destinations, and
so on
44Firewalling 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
45Firewalling Stateful Inspection
46Firewalling Stateful Inspection
47Firewalling Stateful Inspection
- Lets 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)
48Firewalling 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
49Tunneling 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
50Tunneling 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
51Questions?