During our BlackHat US 2014 talk titled "Evasion of High-End IPS Devices in the Age of IPv6", among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:

a) This was not the best way to handle the risk of evasion by abusing IPv6 Extension Headers.

b) In theory there can be nine or more Extension Headers in an IPv6 chain (although in the real world I would be really surprised if we would see that number in production traffic).

Later, at our BlackHat EU 2014 talk with the detailed commands we used) we showed, in the course of our demos, how you can evade Snort by using up to five (5) IPv6 Extension Header per fragment, including the Fragment Extension Header. So, in this case the IPv6 Extensions Headers hard limit described above was actually useless.

When Snort 2.9.7.0 was released on 23^rd of October, a few days after BlackHat EU (coincidence?), in the changelog it was written that “a new config option `max_ip6_extensions` to change the maximum number of IPv6 extension headers decoded” was added. We do not know if this was a reaction to our comment about how Snort handles IPv6 Extension Headers during our first talk or, to the vulnerability disclosed in our second one (for which, by the way, we had informed promptly the Sourcefire/Cisco guys) but in either case, this was definitely good news. So, we decided to try it out.

First, let’s see how you can configure it. At the beginning it wasn’t that clear to me (but I am not the most experienced Snort user either); finally, I found out that you have to add a line like the following to the snort.conf file:

config max_ip6_extensions: 2

Using the aforementioned configuration option, when you send a datagram that contains more than two (2) IPv6 Extension Headers, the following WARNING is triggered:

01/11-16:40:33.391730  [**] [116:456:1] (snort_decoder) WARNING: too many IP6 extension headers [**] [Classification: Misc activity] [Priority: 3] {IPV6-OPTS} fe80::800:27ff:fe00:0 -> fe80::a00:27ff:fe74:ddaa

You can easily reproduce this by using the following Chiron command, which adds a Hop-by-Hop and two Destination Options Headers (please, do not forget to enable the 116:456 Snort preprocessor rule before testing it):

./chiron_scanner.py vboxnet0 -d fe80::a00:27ff:fe74:ddaa -sn -lfE 0,60,60

Of course, you can even minimise the amount of accepted IPv6 Extension Headers by changing the max_ip_extensions to zero (0), as following:

config max_ip6_extensions: 0

Using the latest configuration, a WARNING will be triggered even when just one IPv6 Extension Header is included in an IPv6 datagram. Of course, the number of maximum Extension Headers which each organisation or company will accept/allow in their network depends on their security policy and the IPv6 operational capabilities they want to deploy.

Is this the proper way to fix the security issue of evading Snort by abusing IPv6 Extension Headers? I believe not. The optimum solution would be to avoid evasion even when several IPv6 Extension Headers are accepted. But certainly, it is much better than before, especially taking into consideration that we do not expect to see (at least not yet) even more than one IPv6 Extension Header in Internet/WAN connections in the “real world”.

At the IPv6 Security Summit which will be held during Troopers 15 in the beautiful city of Heidelberg, Rafael Schaefer and I will have the pleasure to review and update the status of two high-end commercial IDPS devices (Tipping Point and Sourcefire) and two open-source ones, including Snort regarding their (in)ability to handle IPv6 Extension Headers properly.

See you all there

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 17^th 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

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 13^th of June and guess what: In 25^th 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:

1. 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 25^th of July, and in 8^th 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.

(to be ...Continued)

During the RISC project, a collaborative project with ERNW.de, we had the change to test several IPv6-capable Security and Netwowrking Devices. Specifically, we had the chance to test the following devices:

● Firewalls:
    –  Cisco ASA 5505 running firmware 9.1(4)
    –  Checkpoint Gaia Release 77.10 running on commodity hardware
    –  Juniper SRX 100H2 running JunOS 12.1X46-DH.2
    –  Fortinet Fortigate 200B running v5.0,build0252 (GA Patch 5)
●  IPS
    –  Tipping Point, TOS Package 3.6.1.4036 and digital vaccine 3.2.0.8530.
●  Layer-2 switch
    –  Cisco Catalyst 4948E running Cisco IOS Release 15.2(1)E1.

We performed several tests and the results quite interesting security-wise. Both the IPS and the Cisco Switch could be evaded (although the last case was already known). Especially as far as the IPS is concerned, we could make it completely "blind" and to fly under it's radars no matter what kind of attack we launched. The other devices appeared to have some minor issues too.

We also checked the aforementioned devices regarding their RFC-compliance, as well as how IPv6-Ready really other. Are they going to face any operational issues when deployed?

The full presentation with all the results, as presented during the IPv6 Security Summit @ Troopers 14, can be downloaded from here.