Saturday, 12 March 2016

IETF RFC 7707: Network Reconnaissance in IPv6 Networks


The IETF has just published RFC 7707, authored by Fernando Gont and Tim Chown. This RFC could probably be considered the "bible" of "IPv6 Network Reconnaissance", describing the state of the art in IPv6 Network Reconnaissance.

Besides its value in terms of analyzing a plethora of vectors for IPv6 network reconnaissance, this document has been valuable for triggering other work in the area of IPv6 addressing. Namely,

  • "Recommendation on Stable IPv6 Interface Identifiers" (draft-ietf-6man-default-iids)
  • "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" (RFC 7721)
  • "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" (RFC7217)

These efforts are in the process of formally updating IPv6 Stateless Address Autoconfiguration (SLAAC) in the hopes of mitigating a number of security and privacy issues arising from traditional IPv6 SLAAC (which typically embeds link-layer addresses in the Interface Identifiers), and has already led to changes in Linux implementation of SLAAC, thanks to the work of Hannes Frederic Sowa and others in NetworkManager and the Linux Kernel.

Enough said! -- Please take a look at RFC 7707.

Tuesday, 16 February 2016

Quiz: Weird IPv6 Traffic on the Local Network (updated with solution)


One thing that I enjoy a lot is capturing network traffic to subsequently try to figure out whether the captured traffic makes any sense -- you learn a lot that way.

The following packet was shared with me by Timo Hilbrink during the 10th Slovenian IPv6 Summit.

The quiz consists in explaining the packet trace bellow.

Actors:
  • Apple iOS 8.3
  • Fritz!Box CPE

The "Crime Scene" (tcpdump packet trace):

Two packets:

19:00:02.246726 IP6 truncated-ip6 - 16011 bytes missing!(class 0x50, flowlabel 0x00040,
hlim 0, next-header unknown (64) payload length: 16035)
4006:a0bd:c0a8:b229:40e9:a79c:f129:50 > f141:8159::b002:ffff:32fc:0: ip-proto-64
16035
19:00:02.252529 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 256)
fe80::be05:43ff:feea:be92 > ip6-allnodes: [icmp6 sum ok]
ICMP6, router
advertisement
, length 256
hop limit 255, Flags [other stateful], pref high, router lifetime 1800s, reachable time
0s, retrans time 0s
prefix info option (3), length 32 (4): 4006:a0bd:c0a8:b229::/64, Flags [onlink, auto],
valid time 7200s, pref. time 0s
prefix info option (3), length 32 (4): 4006:11b:c0a8:b229::/64, Flags [onlink, auto],
valid time 6973s, pref. time 0s
prefix info option (3), length 32 (4): 4006:3e38:c0a8:b229::/64, Flags [onlink, auto],
valid time 6972s, pref. time 0s
prefix info option (3), length 32 (4): 2001:980:376d:1::/64, Flags [onlink, auto], valid
time 6603s, pref. time 3600s
rdnss option (25), length 24 (3): lifetime 1200s, addr: fd00::be05:43ff:feea:be92
mtu option (5), length 8 (1): 1500
unknown option (24), length 8 (1):
0x0000: 0008 0000 0708




So... can you explain what this packet trace is all about?

Solution:

The solution to this quiz boils down to explaining the two packets in question.

Upon first inspection, the first packet looks like a malformed/corrupted IPv6 packet: the packet is truncated, has an IPv6 Source Address that does not really belong to the local subnet, and even has an unknown upper protocol (Next Header=64). Quite surprisingly, the second 32-bits of the IPv6 Source Address are c0a8:b229 which, if converted to decimal on a byte-by-byte basis, results in 192.168.178.41.

Is this just a coincidence? -- Let's look at the first packet a bit closer, with Wireshark:



Looking at the packet decode, it's clear that while the Ethernet "Type" field is set to 0x86dd (IPv6), the IPv6 version field is actually set to version 4!

What we infer from this packet, is that the sending system (Apple iOS 8.3) fails to properly set the Ethernet Type field (i.e., bug #1). Hence, this IPv4 packet is identified at layer-2 as an IPv4 packet, and hence parsed as an IPv4 packet.

This is what the packet should look like (but doesn't):





Now.. what about the second packet? How and why is it actually generated?

First of all, it seems that the Fritz!Box CPE fails to perform a very simple sanity check: that the IP version field matches the protocol type identified by the Ethernet header. In this particular case, they do not patch, and the Fritz!Box CPE should have discarded the packet rather than process it (i.e., bug #2).

That said, the Fritz!Box CPE seems to detect that the sending system is sending packets from an incorrect IPv6 prefix, and hence sends a Router Advertisement message with a Prefix Information Option (PIO) that advertises the corresponding prefix with a preferred lifetime of 0 -- in the hopes that this prefix is "disabled" in the sending system. This seems to be some sort of feature of the Fritz!Box CPE that aims to mitigate e.g. misconfigurations. Obviously, in this particular case the RA sent by the Fritz!Box CPE will be of no use, since the sending system is not really employing the 4006:a0bd:c0a8:b229/64 prefix -- it is simply sending IPv4 packets with an incorrect Ethernet Type (0x86DD rather than 0x800).

So... what's the real IP packet that is being sent by Apple iOS 8.3? If we overwrite the incorrect EtherType of the first packet with 0x0800, and now decode the first packet again (such that it is decoded as an IPv4 packet rather than as an IPv6 packet), the output is:

19:00:02.246726 IP 192.168.178.41.61737 > 64.233.167.156.80: Flags [S], seq 4047602009, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1228667736 ecr 0,sackOK,eol], length 0

That is, the first packet of the packet trace was really an IPv4-based TCP SYN packet, which obviously looked like a malformed IPv6 packet when "incorrectly" decoded as an IPv6 packet.

Folks willing to take a closer look at the packet trace may find the corresponding pcap file here. The "corrected" pcap file (with the EtherType overwritten with 0x0800, such that the first packet is decoded as an IPv4 packet) can be found here.

  -- Fernando Gont

Friday, 5 February 2016

RFC7739: Security Implications of Predictable Fragment Identification Values


The IETF has published a new RFC by Fernando Gont: RFC7739.

This RFC analyzes the security and privacy implications of predictable Fragment Identification (ID) values, and proposes a number of algorithms that can be employed to select Fragment ID values such that the aforementioned issues are mitigated.

As a result of earlier (internet-draft) versions this document, a number of operating systems (ranging from Linux to Microsoft Windows) had patched their IPv6 implementations to mitigate the aforementioned issues.

Recent discussions at the IETF suggest that the upcoming revision of the core IPv6 specification will remove the suggestion to employ a global counter for the generation of IPv6 Fragment IDs.

Use of predictable identifiers have a long history in IETF protocols, as discussed in this recent internet-draft by Fernando Gont and Iván Arce.


Friday, 29 January 2016

New edition of "Hacking IPv6 Networks v3.0" (May 31 - June 2, 2016 - Stuttgart)


Fernando Gont will be teaching our renowned "Hacking IPv6 Networks v3.0" training course in Germany!

Date: May 31 - June 2, 2016
Place: Stuttgart, Germany

Learning Objectives:
This course will provide the attendee with in-depth knowledge of IPv6 security, such that the attendee is able to evaluate and mitigate the security implications of IPv6 in production environments.

The attendee will be given an in-depth explanation of each topic covered in this course, and will learn -- through hands-on exercises -- how each feature can be exploited for malicious purposes. Subsequently, the attendee will be presented with a number of alternatives to mitigate each of the identified vulnerabilities.

This course will employ a range of open-source tools to evaluate the security of IPv6 networks, and to reproduce a number of IPv6-based attacks. During the course, the attendee will perform a large number of exercises in a network laboratory (with the assistance of the trainer), such that the concepts and techniques learned during this course are reinforced with hands-on exercises. The attendee will be required to perform a large number of IPv6 attacks, and to envision mitigation techniques for the corresponding vulnerabilities.

More information about the training course, and online registration is available here.

Tuesday, 1 December 2015

The Controversial IPv6 Extension Headers


IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for core functionality such as IPv6 fragmentation. The typical structure of an IPv6 packet containing IPv6 extensions headers is as follows:



Common implementation limitations suggest that IPv6 extension headers present a challenge for a plethora of device types, and recent studies indicate that there exists widespread dropping of IPv6 packets containing extension headers.

The topic of IPv6 extension header typically triggers heated discussions in the technical communities between network engineers claiming that IPv6 extension headers are key to future innovation, versus security specialists that quite frequently argue that IPv6 extension headers represent a security nightmare.

Given the ongoing debate on this topic, we believe the following resources can help in raising awareness about the challenge represented by IPv6 extension headers and their current operational status.

A first set of resources comprises a number of TechTarget articles on this topic:
A more thorough discussion of these issues can be found in these IETF Internet-Drafts:
The above resources give a clear signal that, if IPv6 extension headers are to usable in the public Internet, there is a lot of work to be done by the IETF itself, software developers, hardware manufacturers, and the operational community as a whole.

Tuesday, 25 August 2015

IETF RFC 7610: "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers"

We have just published IETF RFC 7610, entitled "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers". The abstract of the RFC is:
This document specifies a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers.  It is based on
DHCPv6 packet filtering at the layer 2 device at which the packets
are received.  A similar mechanism has been widely deployed in IPv4
networks ('DHCP snooping'); hence, it is desirable that similar
functionality be provided for IPv6 networks.  This document specifies
a Best Current Practice for the implementation of DHCPv6-Shield.

We hope that this RFC will help in achieving parity of security features with IPv4.

Monday, 20 February 2012

IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly

Introduction

More than ten years ago, Ptacek and Newsham published a seminal paper on network instrusion evasion, entitled "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", in which they described how ambiguity in the "reassembly" function of protocols such as TCP and IP could be leveraged to evade Network Intrusion Detection Systems. Essentially, the attacker causes the security device to obtain a different data stream from that obtained by the victim system, such that he is able to conceal his attack traffic from the security device while still successfully performing the attack against the victim system.

Recently, we assessed the fragmentation and reassembly policies of some popular IPv6 implementations, such that we could evaluate the feasibility of IPv6-fragmentation-based insertion/evasion attacks with current IPv6 implementations (similar to those described by Ptacek and Newsham for IPv4). The aforementioned assessment was not "casual", but was mostly motivated by recent improvements in the IPv6 fragmentation and reassembly implementations of a number of popular IPv6 stacks. The improvements mostly fall into these categories:


As one might expect, all of these aspects are intimately related, and interact with each other in most scenarios.

This article discusses the first two items: the basic fragment reassembly policy of some popular IPv6 implementations (item #1 above) and the processing of IPv6 atomic fragments (item #2 above) of such implementations.
The discussion of the fragment Identification generation is left for future posts.

Assessing the fragment identification policy of popular implementations

Based on previous experience with IPv4 fragmentation and reassembly, we selected a total of five tests to be performed with each of the target implementations, to infer their IPv6 fragment reassembly policy. Each test involves sending a fragmented ICMPv6 Echo Request message of which some fragments have total or partial overlap, and then analysing the corresponding "response". The possible responses to the aforementioned probes are:
  • An ICMPv6 Echo Reply message, from which the fragment reassembly policy can be inferred (i.e., which copy of the data was used for the reassembled packet),
  • A time-out, implicitly signalling implementation of RFC 5722, or, 
  • An ICMPv6 Time Exceeded error message, implicitly signalling implementation of RFC 5722.

The tests performed on each IPv6 implementation are as follows:
Test #1

Frag. #1:  AAAAAAAAAAA
Frag. #2:         BBBBBBBBBBB


Test #2

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:         CCCCCCCCCCC


Test #3

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:            CCCCCCCCCCC


Test #4

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:            CCCCCCCCCCCCCCCCCCCCCCCCCC


Test #5

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:                           CCCCCCCCCCC
Frag. #4:            DDDDDDDD


The results of the aforementioned test for different implementations are:


OS Test #1Test #2Test #3Test #4Test #5
NetBSD 5.0ICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
OpenBSD 5.0First copyFirst copyLast copyLast copyFirst copy
OpenBSD-currentTime OutTime OutTime OutTime OutTime Out
FreeBSD 9.0ICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
Linux kernelICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
Windows XP SP2Time OutTime OutTime OutTime OutTime Out
Windows Vista (Build 6000)Time OutTime OutTime OutTime OutTime Out
Windows 7 Home PremiumTime OutTime OutTime OutTime OutTime Out

Clearly, all current implementations are converging towards the implementation of RFC 5722.


Processing of IPv6 atomic fragments

A special case of IPv6 fragments is that in which a fragment has a Fragment Offset of 0 (i.e., it is the first fragment), and at the same time has the "M" (More fragments) bit set to 0 (i.e., it is the last fragment). While these packets might seem non-sensical/non-legitimate, there are a number of scenarios, notably those in which IPv6/IPv4 translators are employed, in which these fragments may be legitimately generated.
Unfortunately, some implementations mistakenly consider atomic fragments as illegitimate, and silently drop them, causing an interoperability problem in scenarios in which nodes rely on atomic fragments.

What makes these fragments special is that, being both the first and the last fragment at the same time, they are "atomic" fragments -- no other fragments are needed for the "fragment reassembly" to be performed.

Unfortunately, some implementations don't take advantage of the "atomic" property of these fragments, and may "mix" atomic fragments with regular fragments (if such fragments are present in the fragment reassembly queue when the atomic fragment is received). That is, if one of such implementations receives an atomic fragment with the same set (IPv6 Source Address, IPv6 Destination Address, Fragment Identification) as that of a fragment already present in the reassembly queue, and e.g. both fragments overlap, the two fragments will be processed as regular overlapping fragments (e.g., "silently dropped" if the stack implements RFC 5722). This sub-optimal processing allows an attacker to launch any fragmentation-based attack against traffic flows employing atomic fragments, while the improved handling successfully mitigates such attacks, since the atomic fragments are essentially processed as non-fragmented traffic.

The following table contains a summary of the assessment of a number of popular IPv6 implementations with respect to the processing of IPv6 atomic fragments:

OSAtomic Fragment SupportImproved Processing
FreeBSD 8.0 No No
FreeBSD 8.2 Yes No
FreeBSD 9.0 Yes No
Linux 3.0.0-15 Yes Yes
NetBSD 5.1 No No
OpenBSD-current Yes Yes
Solaris 11 Yes Yes
Windows XP SP2 Yes No
Windows Vista (Build 6000) Yes No
Windows 7 Home Premium Yes No


Ongoing work in the area of IPv6 fragmentation and reassembly

There is ongoing work at the IETF in the area of IPv6 fragmentation and reassembly. Part of that work is being carried out in the following documents:

  • draft-gont-6man-oversized-header-chain: Discusses the security implications that may arise from (among other reasons) small IPv6 fragments (individual submission by Fernando Gont and Vishwas Manral).

    These documents are being formally discussed on the 6man wg mailing-list, although they have also received their share of discussion on the ipv6hackers mailing-list, and on LACNIC's security forum mailing-list (in Spanish).

    Feedback from the security and developer community is key to arrive to the best possible security-wise specifications, which will hopefully reflect into improved IPv6 implementations.


    Conclusions

    IPv6 implementations are converging towards the implementation of RFC 5722, which forbids overlapping fragments. This is a clear improvement over the IPv4 case, in which overlapping fragments are allowed, and hence insertion/evasion attack are harder to detect.

    In a similar way, IPv6 implementations are slowly converging towards the implementation of the improved processing of IPv6 atomic fragments specified in draft-ietf-6man-ipv6-atomic-fragments. The aforementioned improved processing is key to avoid a number of fragmentation-based attacks that would otherwise be more trivial to perform in IPv6 than in IPv4.

    It should be noted, however, that it will take time until some legacy implementations that implement neither RFC 5722 nor draft-ietf-6man-ipv6-atomic-fragments are phased out. Until that happens, those legacy implementations may still be subject to the similar insertion/evasion attacks than those that have traditionally been applied on IPv4 networks, and they may also be subject to some fragmentation-based attacks that could be performed in previously-unavailable ways.