This is a guest post from Antonios Atlasis.
Yesterday we (Rafael Schaefer, Enno and me) had the pleasure to deliver together our talk at BlackHat Europe 2014 named Evasion of High-End IDPS Devices at the IPv6 Era (by the way, latest slides can be found here and the white paper 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.
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.
Have a great weekend
Antonios
Have you contacted the:
– cisco tac team (tac@cisco.com) andò in particolar the cisco psirt team (psirt@cisco.com) ?
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
Roberto,
thanks for the link and your question.
Having dealt with them, in a quite cooperative manner, many times (actually since Gaus’ early days there, 2004 or so – pity he seems no longer to be with them) we’re well aware of Cisco PSIRT and their role.
This time we didn’t go through PSIRT, for mainly two reasons:
– initial contact was established to Snort/Sourcefire team before the acquisition and we tried to follow up via the same channels.
– we did not consider our findings as “security vulnerabilties” in the first place but as “deficient core properties of the product” which then had to be handled by “the guys closely related to the product”. To give you an analogy: if a car has a problem with tire pressure – which _could_ lead to an accident and hence be considered a safety problem – would you then contact the car manufacturing people themselves [namely their “tire guys”] or their security department? We chose the former.
Suffice to say that at least five (5) people with a @cisco.com email address were involved in various communication acts (all of which included many details and, upon request, pcap files). And, yes, at some point we were just no longer interested in adding more parties (like PSIRT) to the procedure. Why would we? Enough energy was spent already… “if the tire guys don’t see a problem with the tires failing”…
Please allow to cite another vendor which we reported similar problems to in the following:
“They [ed.: our reports] are friendly, detailed and accurate. Doesn’t get much better, so please keep it up!”
From our perspective we tried hard. At some point we realized that – probably due to the merger – priorities were set otherwise, on the Sourcefire/Cisco side.
Best
Enno
Didn’t you already have the answer for this? You published it in your blackhat paper at least.
https://www.blackhat.com/docs/us-14/materials/us-14-Atlasis-Evasion-Of-HighEnd-IPS-Devices-In-The-Age-Of-IPv6-WP.pdf
116:456 handles this case perfectly well. That you assert the traffic is valid is no more meaningful than asserting that ipv4 source routing is valid, that telnet is valid, that digest auth is valid, that double encoded http is valid, etc. When you see any of these things in places you shouldn’t it should just be blocked. No need to look for attacks, the traffic itself is an indication of bad.
@Jason.
The case that you mention about Snort is the one reported in June. Unfortunately, the completely new cases that we discovered and reported in early September, are not handled by 116:456.
We clearly mention this in our BH EU paper.
Best
Antonios