Sunday, 26 February 2017

New edition of our "Hacking IPv6 Networks v4.0" training-course!


http://securitycongress.euskalhack.org/HackingIpv6.html


In June 20-22, 2017, we will be teaching our renowned "Hacking IPv6 Networks v4.0" training course in San Sebastian, Spain. Registration has already opened!

Course description

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. 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. A range of open source tools will be employed for all the practical exercises, such that the attendee becomes familiar with the tools arsenal that is typically employed for real-world IPv6 security assessments and penetration tests. The attendee will be required to perform a large number of IPv6 attacks, envision mitigation techniques for the corresponding vulnerabilities, and evaluate the aforementioned mitigation techniques with real-world attack tools.

Audience and prerequisites

Network Engineers, Network Administrators, Security Administrators, Penetration Testers, and Security Professionals in general. Participants are required to have:
  • Good understanding of the IPv4 protocol suite (IPv4, ICMP, ARP, etc.)
  • Good understanding of network components (routers, firewalls, etc.)
  • Knowledge of basic UNIX/Linux shell commands
  • Knowledge of basic IPv4 troubleshooting tools, such as: ping, traceroute, and network protocol analyzers
  • Basic knowledge of IPv6 is desirable, but not required.

Course duration, format and materials:

  • Three days, with up to 50% of course time devoted to practical sessions
  • One course book (written by the trainer) that includes all the slides and exercises presented in the course.
  • A copy of the virtual lab employed for the training course.
  • A certificate of completion of the training course.

Other considerations:

  • Coffee breaks and lunch included
  • Training language: English [* Consultar por posibilidad en Español]
  • Students need to bring their own laptop
  • Free admission to EuskalHack Security Congress (Two days Coffee breaks and lunch included)
Please note: Course will be cancelled if the minimum of 8 students do not enroll

About the trainer:

Fernando Gont is a world-renowned IPv6 expert, working on IPv6 consulting around the world:
  • He has written 30 IETF RFCs, many of which focus on IPv6.
  • He is actively involved in IPv6 standardization, with more than 10 active IETF Internet-Drafts.
  • Author of the SI6 Network’s IPv6 toolkit, the only portable and freely available toolkit for the IPv6 protocol suite.
  • He has been delivering consulting and training services worldwide for more than ten years.
  • More information about Fernando Gont is available at his web site: https://www.gont.com.ar.

Detailed training course agenda:   
  1. Introduction to IPv6
  2. IPv6 Addressing Architecture
  3. IPv6 Header Fields
  4. IPv6 Extension Headers (EHs)
  5. IPsec
  6. Internet Control Message Protocol version 6 (ICMPv6)
  7. Neighbor Discovery for IPv6
  8. Stateless Address Auto-configuration (SLAAC)
  9. Dynamic Host Configuration Protocol version 6 (DHCPv6)
  10. Multicast Listener Discovery (MLD)
  11. Upper-Layer Attacks
  12. DNS Support for IPv6
  13. IPv6 Firewalls
  14. Security Implications of IPv6 forIPv4-only Networks
  15. Transition/Co-existence Technologies
  16. Network Reconnaissance in IPv6
  17. IPv6 Deployment Consideration

Please register here!

SDN Hackers Mailing-list

We have created a new mailing-list: SDN Hackers.

This mailing-list is meant to provide forum for SDN hackers to discuss security and low-level issues (e.g. OpenFlow protocol internals) related to the so-called Software Defined Networks (SDN). Subscription to the list is open to the community.

Please subscribe to the mailing-list here.

Thursday, 19 January 2017

A Tale of Bad Decisions, Weird Packets, and DoS Attacks


Last week, RFC 8021, entitled "Generation of IPv6 Atomic Fragments Considered Harmful" was published. Essentially, this RFC suggests that the infamous IPv6 atomic fragments are a bad idea and should not be supported. Besides, it describes an attack vector that, with a single packet, could DoS communications between two systems for about 10 minutes. This vector is the result of the confluence of different issues related to: IPv6 atomic fragments, widespread dropping of IPv6 packets with extension headers, and validation of ICMPv6 error messages.

What are IPv6 atomic fragments?

IPv6 (similarly to IPv4) employs a mechanism called Path-MTU Discovery, that allows IPv6 hosts to discover the maximum packet size that can be used for a given destination. Given that RFC 2460 mandates that the minimum IPv6 MTU be 1280 bytes, hosts would never need to reduce the size of their packets further than to 1280 bytes. But, since IPv6-to-IPv4 translators might be connecting the IPv6 world to the IPv4 world, hosts might receive ICMPv6 PTB packets advertising an MTU smaller than 1280 bytes.

In this respect, RFC 2460 states that, upon receipt of such an error message, a host need not reduce the size of the packets it sends further than 1280 bytes, but should simply include a fragment header in all subsequent packets sent to such destination. Thus, these packets would not really be fragmented into multiple fragments, but would just include a fragment header with (Fragment Offset=0, MF=0)

These packets were supposed to help translators in selecting a proper IPv6 fragment identification value. But please see the analysis in RFC 8021.

IPv6 atomic fragments have been problematic for a number of reasons:
  • Many implementations were processing atomic fragments as normal fragmented traffic, allowing attackers to perform DoS attacks by sending forged IPv6 fragments that would cause the reassembly process to fail. This was eventually fixed by RFC 6946.
  • Many implementations were (and some still are!) employing predictable IPv6 fragment identification values, allowing a number of different attacks. This has been documented in RFC 7739, but the specifications were never formally updated to require unpredictable fragment identifiers.
  • Atomic fragments are the only case in which the use of extension headers can be actually triggered by a third party (including an attacker).

Dropping of IPv6 Packets with Extension Headers 

As documented in RFC 7872, entitled "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", there is widespread dropping of IPv6 packets containing extension headers in the public Internet.Besides, it is not unusual for e.g. BGP routers to drop IPv6 fragments targeted at them to protect the control plane.

A discussion of this topic can be found here.

Validation of ICMPv6 Error Messages

ICMP(v4) error messages were well-known as a DoS attack vector (remember the IRC nukes from the '90s?). Still, as late as 2005, a large number of implementations were not performing any validity checks on such messages. While many/most IPv4 implementations were eventually patched, the IETF specifications were never formally updated to mitigate ICMP-based attacks. The only effort at the IETF to mitigate this problem, RFC 5927, took six years to be published (2004-2010), and never formally updated any specifications because of opposition within the TCPM WG of the IETF -- the document was simply published as an Informational RFC.

The latest revision of the ICMPv6 specification (RFC 4443), briefly commented on the topic, but never changed the state of affairs in this respect.

Thus, many ICMPv6 implementations (as ICMP implementations of the '90s), simply fail to perform any validity checks on the received ICMPv6 error messages -- many don't even check if the received ICMPv6 error message corresponds to an ongoing session.

Putting the Pieces Together

Based on the analysis above, we have the following pieces:

  • Packets with IPv6 extension headers widely dropped
  • Possibility to trigger the use of extension headers (fragmentation) with ICMPv6 PTB packets
  • Implementations not performing any validity checks on received ICMPv6 PTB packets
 As a result, it should be obvious what the attack is all about.

What is worse, many of the "mitigations" that might be in place to protect from attacks will not even work against this attack. For example,

  • Network ingress filtering (BCP 38) will not mitigate the attack, since the source address of ICMPv6 PTB messages need not be forged
  • Things like the TCP MD5 option protect the application data stream, but have no effect on ICMPv6 error messages
  • Many firewall implementations do not allow ICMPv6 PTB messages to be filtered based on the MTU value that they advertise

Reproducing the Attack

The icmp6 tool of the SI6 Network's IPv6 Toolkit can be readily employed to reproduce this attack. A simple way to reproduce this attack is to target the communication between our connection with a web server. Let us assume that our host's IPv6 address is 2001:db8:2::100 and a web site is being served by 2001:db8:1::1. We could test the attack vector with the following steps:

  1. Test the communication with the server, e.g. by using telnet, as follows:
    $ telnet 2001:db8:1:1 80
    This connection attempt should succeed.
  2. Launch the attack by employing the icmp6 tool of the SI6 Networks' IPv6 Toolkit as follows:
    # icmp6  --icmp6-packet-too-big -d 2001:db8:1::1 --peer-addr 2001:db8:2::100 --mtu 1000 -o 80 -v3
  3. Test communication with the web server, as in the first step. This new connection attempt should now timeout.
Many implementations do not even check that the ICMPv6 PTB message refers to an ongoing session (e.g., TCP connection). In such cases, it is not even needed to specify the TCP port numbers involved.

IoT Hackers Mailing List

We have created a new mailing-list: IoT Hackers.

It is meant to provide forum for security researchers and networking professionals to discuss low-level networking and security issues related to IoT security and IoT networking.

Subscription to the list is open to the community. However, posts to the list from new subscribers will be moderated, in order to keep an acceptable signal/noise ratio.

Please subscribe here!

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.