This is a guest post from Antonios Atlasis.
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 3.6.1.4036 and vaccine 3.2.0.8530 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.
Specifically, while checking the detection capabilities of Suricata version 2.0.1 (with Emerging Threats ETOpen Ruleset, 03 June, 2014), we found out that it can be evaded when:
- An IPv6 Destination Option header is used as part of the fragmentaple portion of the IPv6 datagram.
- The IPv6 Destinations Option header is padded with at least six (6) octets of bytes.
- The IPv6 datagram is fragmented in at least 7 fragments, which are sent mis-ordered (this is actually the key).
The aforementioned technique is displayed in the following figure:
In the above example:
a. Ten (10) fragments are used (as I have mentioned, we have found that seven would be enough though).
b. The TCP header is encapsulated in the last 3 fragments (with offsets 7, 8 and 9), while the other fragments encapsulate the Destination Options header (which is padded to have enough size to be split in seven fragments, in our example).
c. The fragments are sent misordered; specifically, the first fragment (the one with offset equals to 0) is sent last, while the order of the rest remains the same. This can also vary though.
For our testing purposes, we made sure that all IPv6-related signatures are enabled and we also created a rule that detects any TCP traffic destined to port 80 (normally used for HTTP traffic), as well as a rule that detects any ICMPv6 Echo Requests (aka ping) messages. By using the aforementioned techniques, such traffic can be sent to the target without triggering any alert, neither the custom ones, nor the IPv6-specific ones.
It should be noted that when we say that Suricata is evaded by this technique, this is the case no matter what the actual attack is, i.e. the attack can be from “simple” port scanning to any layer-5 attack, like SQLi or XSS.
In this technique though, the layer-4 header has to be in a fragment other than the first in order to be effective. Hence, when finally RFC 7112 will be implemented, these fragments will not be considered to be legitimate and so, they should/may be dropped.
It should also be noted that not all Operating Systems (OS) respond to such packets. However, the following ones happily respond to them:
- Centos 6.5
- Windows 2012R2
- OpenBSD 5.5
- Windows 8.1
On the contrary, Fedora 20 and FreeBSD 10 do not respond to such packets. So, if you want to use this technique to evade Suricata version 2.0.1 (and possibly earlier), your target OS should not be one of the last two in order to trigger a response.
We reported this issue to the Suricata developers in 13th of June and guess what: In 25th of June there was already a new release, version 2.0.2, where the pre-described issue had been fixed. Well done guys! You impressed us!
However, since research never stops, a young student doing his thesis at ERNW and working under the RISC (Researching IPv6 Capabilities) ERNW project, named Rafael Schaefer, continued to work on this and here it is what he found out. The latest (up to yesterday) Suricata version 2.0.2 (with Emerging Threats ETOpen Ruleset – 21.7.2014, built from source) can also be evaded under the following different cases:
- An IPv6 datagram fragmented in two fragments, each one consisting of:
- An IPv6 Hop-by-Hop Option header with the “RouterAlert” option in the unfragmentable part of each fragment.
- An IPv6 Destination Option header padded with at least six (6) octets of bytes splitted in the two fragments.
(NOTE: The problem is not related with the specific IPv6 Extension Headers; instead, other IPv6 Extension Headers can also be used.)
The diagram that describes this rather trivial and actually known technique (but still effective though) is displayed below:
(NOTE: This is actually similar to the one used in RA-Guard Evasion as well as in other cases, but, as I said, it is still effective).
2. An IPv6 datagram (with or without Extension Headers, it doesn’t matter in this case) that is fragmented in two fragments, which are sent with a delay of ~59.8 seconds in between (cool, isn’t it? It reminds me a similar issue that I had found regarding OpenBSD 5.3 and earlier). Because precision does matter :).
3. An IPv6 packet with an unknown (non-existing yet) Extension Header (e.g. having a next Header value equal to 200) OR an Extension Header not supported yet (e.g. the Shim6 one) OR in combination with other Extension Headers.
From the last three issues, only the first one would have been solved if RFC 7112 had been implemented. The second one can be used without Extension Headers and the third one without fragmentation.
All the latest problems were reported in 25th of July, and in 8th of August, version 2.0.3 was released which fixes all these issues. We were impressed again, but we were not suprised this time. I just wish we had such a fast reaction from commercial vendors too ;).
Again, this is not the end. We will come back soon. Promise. But with a commercial device this time.
Have a great weekend everybody
Antonios
PS: The slides of our Black Hat talk on the topic can be found here.