Taking the chance from a discussion on the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, I decided to test very quickly what is the current status related with the latest and some of the most poplar Operating Systems (OS) status (whether they send Atomic Fragments in response to Packet Too Big messages, or not). The motivation behind this was to check which one of them is potentially vulnerable to the DoS attack using the technique described in the above proposed RFC and taking it for granted that Atomic Fragments are blocked in the real world (but more about this, in another blogpost in the near future).
In the “A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices” blogpost I described a way to evade a high-end commercial IDPS device, the Tipping Point IDPS (TOS Tipping Point, Package 188.8.131.5236 and vaccine 184.108.40.20630 digital), by abusing a minor detail at the IPv6 specification. As I promised at the end of that blogpost, this is not the end. In this blogpost I am going to describe several new and different ways of evading another popular IDPS, an open-source one this time, Suricata.
As it is well known to the IPv6 enthusiasts, one of the most significant changes that IPv6 brings with it, apart from supporting a really huge address space, is the improved support for Extensions and Options, which is achieved by the usage of IPv6 Extension headers. According to RFC 2460, “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.” So, by adding IPv6 Extension headers, according to the designers of the protocol, flexibility and efficiency in the IP layer is improved.
This illustrates once more the huge security problems related to IPv6 extension headers and IPv6 fragmentation and in particular to the combination of those two. Antonios Atlasis will discuss those in detail at the event (see his announcements here and here). It would be really helpful if major security products had some simple global properties/command line parameters/checkboxes like “drop all fragmented IPv6 packets”, “drop all IPv6 packets with extension headers” (ok, maybe “drop all IPv6 with multiple extension headers”; besides HBH in MLD packets – which shouldn’t traverse L3 hops – we don’t see too much ext headers in production networks anyway, as of early 2013) or at least “drop all packets with a combination of fragmentation and ext headers other than the fragmentation header”. But this will probably need another some years to show up and unfortunately we’ll probably see such problems still for a very long time…
Again, you should see Antonios’ presentations on this stuff (I had the chance to look at them already, it’s great research with scary results). For those of you who can’t join us: they’ll be made available for download after the conference.
Looking forward to an active discussion of these topics at the IPv6 Sec Summit,