About two weeks ago we (Rafael Schaefer, Enno and me) had the pleasure to deliver our talk at BlackHat Europe 2014 named Evasion of High-End IDPS Devices at the IPv6 Era (by the way, latest slides and the white
paper can be found here). In this talk we summarised all the IDPS evasion techniques that we have found so far. At previous blogposts I
had the chance to describe how to evade Suricata and TippingPoint. In this post I am going to describe some other techniques that
can be used to evade Snort, and its companion commercial version, Sourcefire. The tool used to evade these IDPS
is – what else – Chiron (Chiron can be downloaded
here)
The versions that we used for our tests are the latest available ones at the time of this writing, that is:
- Sourcefire, Model 3D7020 (63) Version 5.2.0.3 (Build 48), VDB version 216.
- Snort 2.9.6.2 GRE (build 77), Registered User’s Release Rules.
As an “attacking” vector, for reasons of simplicity we considered the ICMPv6 Echo Request message. That is, we enabled the rule that detects such messages and we tried to deliver our packet without being blocked or triggering an alert (during our tests, Sourcefire was used inline while Snort in parallel).
In both devices we enabled some additional rules that come disabled by default in order to make our evasion attempts harder and, possibly, more realistic. To this end, we enabled the Preproc decoder rules GID 116 family and specifically, the ones with SID 458 (IPV6_BAD_FRAG_PKT), 272 and 273. These rules detect some of the attacks that have been reported in the past.
However, even doing so Sourcefire can be evaded by using the following arbitrary IPv6 header chain:
a. The unfragmentable part consists of three (3) Destination Option headers.
b. The fragmentable part consists of two (2) Destination Option headers plus the layer 4 header.
c. The aforementioned datagram is split in two fragments, as shown in the figure:
A Wireshark output of the above technique is displayed below:
We should note that when we enable the rule with SID:296 an alert is triggered (“DECODE_IPV6_UNORDERED_EXTENSIONS”) but there is no alert about ICMPv6 Echo Request (our “attack” itself). Furthermore the problem with this rule is that it also triggers alerts when fully legitimate and RFC compliant packets with IPv6 Extension headers are used (= false positives). Hence, there is a doubt whether this would be useful to a real working environment since it can rather confuse the intrusion analysts with the produced false alarms. So, this does not seem to be a realistic and effective way of detecting any kind of attacks when specific arbitrary IPv6 header chains are used.
However, the aforementioned technique does not work against latest Snort. Probably because latest Sourcefire is based on Snort 2.9.6, while latest Snort release is 2.9.6.2. Anyway, we did not bother that much. We tried to find an evasion technique that works against Snort too. And here it is. To do so, the IPv6 header chain must consist of:
a. An unfragmentable part, which consists of a Hop-by-Hop header, a Type 3 Routing header and a Destination Options header.
b. A fragmentable part, which consists of a Destination Options header, the layer-4 header and its payload.
c. The fragmentable part is split in two fragments, as displayed in the next figure:
As you can easily notice, first, the latest technique is actually a variation of the previous one and secondly, this last case could be a fully legitimate combination of IPv6 packets (OK, unless RFC 7112 is implemented, of course). A final note: This last technique works also against Sourcfire.
Now, the sad side of the story.
We first tried to contact the Snort developers on 17th of June for reporting a previous issue. They asked us to send a pcap file, which we did. Unfortunately, we haven’t heard back from them yet. Then, we reported the aforementioned issue to Sourcefire on Sep 14th, as well as to Cisco on Sep 25 (since now Sourcefire has been acquired by Cisco), including pcap files. Their reaction?
“If you are concerned about Sourcefire product, I suggest that you contact … customer support versus emailing … directly”
Well, sorry guys, but we just tried to help; we do not need any customer support. [for the record: we even tried that given we had some cases/tickets from an ongoing customer project, to no reasonable avail.]
On the contrary, we must say that during our tests and the process of discovering IDPS evasion techniques, the Suricata developers had always the fastest
reaction (patching each reported issue in about a week) and, they also say …thank you. On
the other hand, TippingPoint, when we reported to them two vulnerabilities, they preferred to patch them
…silently.
Anyway, we are pretty sure that Snort and Sourcefire are going to fix these issues at some point. In the meantime, enjoy IPv6 ;).
For more info regarding the techniques and each specific case (including Suricata and TippingPoint), please check our white paper.
Best
Antonios
Write a comment