This is a guest post from Antonios Atlasis
IPv6 introduces a lot of new features and consequently, a lot of new capabilities. Obviously, the most significant of them is the huge address space that it offers. However, this is not the only one. IPv6 also introduces the use of the IPv6 Extension Headers. The IPv6 header has been considerably simplified in comparison with IPv4 one. On the other hand, the IPv6 Extension Headers, not only do the “job” of most of the fields which were removed from the main header, but, additionally, they add many more. However, any new “technology” creates new attack opportunities and a “new” protocol, such as IPv6 could not be an exception, especially since its design and implementation is more complicated than it’s predecessor.
RFCs describe how the IPv6 Extension Headers SHOULD be used. And the various products (from Operating Systems (OS) to security and network devises) do not necessarily comply with them. On the contrary, many of the OS appear to have their own unique behaviour. To make matter worse, in several cases it is not specified how an OS should react if a non-compliant packet is received.
In the IPv6 Security Summit 2013 that will be held during the Troopers 13 Security Conference, the new features as well as the new attack vectors that the IPv6 Extension Headers bring with them will be discussed during the IPv6 Extension Headers: New Features, and New Attack Vectors presentation. As it will be shown, the abuse of IPv6 Extension Headers in a way not predicted by the corresponding RFCs (and in some cases in way that it is allowed by them) can lead to significant security impacts. To this end, the effectiveness of some of the most popular Operating Systems on handling various malformed IPv6 datagrams will be examined. These security impacts can be exploited for various purposes, such as for evading IDS, for creating covert channels by hiding data into Extension headers, etc. During a live demo, the effectiveness of two of the most popular open-source IDS against these attacks will be examined and ways for evading them at the IP level will be discussed. And since this is a layer-3 protocol, any security flaws will affect not only this protocol itself but, moreover, any upper-layer one that relies on it.
Based on the findings, we will reach our final goal. To identify any potential implementation or design weaknesses and to propose specific countermeasures and security improvements. Not only the vendors should more carefully implement the IPv6 capabilities of their products before claiming to be “IPv6 Ready”, but, moreover, some RFCs may have to be updated. By drawing our conclusions, we will come up for a discussion and, why not, with ideas and proposals to improve them.
IPv6 is at the gates and it cannot wait any more. So, let’s get prepared for it.