Wed

04

Feb

2015

How to Configure Snort to Stop IPv6 Evasion Attacks

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 23rd 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 :)

0 Comments

Tue

28

Oct

2014

A “Please, Don’t Waste my Time” Approach and the Sourcefire/Snort Evasion

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:

headers1

A Wireshark output of the above technique is displayed below:

headers2

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:

headers3

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

0 Comments

Sat

16

Aug

2014

Evading Suricata by Combining IPv6 Extension Headers and Fragmentation “Features”

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:

 

suricata_offsets_smaller2

 

 

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:

 

  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:

 

 

 

suricata_hdrs_smaller2

 (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.

(to be ...Continued)

0 Comments

Tue

27

May

2014

A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices

(or, How the Smallest Detail can Make the Difference)

As it is well known to the IPv6 enthusiasts, one of the most significant changes that IPv6 brings with it, apart from supporting a really huge address space, is the improved support for Extensions and Options, which is achieved by the usage of IPv6 Extension headers. According to RFC 2460, “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.” So, by adding IPv6 Extension headers, according to the designers of the protocol, flexibility and efficiency in the IP layer is improved.

 

This can definitely be the case, but apart from it, it has already been shown that by abusing IPv6 Extension headers several security issues may arise (see for example my presentations at Black Hat Abu Dhabi 2012 and at the IPv6 Security Summit @ Troopers 13). This is why Enno Rey by talking straight to the point at the latest IPv6 Security Summit @ Troopers 14 described the IPv6 Extension headers as a “mess”!

 

Unfortunately, it seems that we have not exhausted yet all the potential security problems introduced by IPv6 Extension headers. In this article, I am going to describe a novel way of abusing IPv6 Extension Headers which can be used to evade successfully high-end IDPS commercial devices. Specifically, during the “Researching IPv6 Security Capabilities” (RISC) project organised by ERNW and in which I had the pleasure to participate, we found out that using this technique, we can evade the Tipping Point IDPS (for a full presentation of the results of the 1st phase of RISC which were presented at the IPv6 Security Summit @ Troopers 14, please check here). But, before describing how it works, let's build our case first.

 

As it is explained in RFC 2460, “in IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper- layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value.” According to the protocol specification, “an IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header.

 

Let's assume that the initial IPv6 datagram that needs to be fragmented contains the IPv6 main header (obviously), a few IPv6 Extension headers and the layer-4 header (e.g. TCP) plus its payload. Some of the IPv6 Extension headers (like the Hop-by-Hop and the Routing IPv6 Extension headers) may need to be processed by intermediate nodes, while some other (e.g. Destination Options IPv6 Extension header) may not. A part of this initial IPv6 datagram will remain unfragmented, and the rest of it will be fragmented as following:

 

The Unfragmentable Part will consist of the IPv6 main header plus any IPv6 Extension headers that must be processed by intermediate nodes en route to the destination (Hop-by-Hop and the Routing IPv6 Extension headers in our example).

 

The Fragmentable Part will consist of the rest of the packet, that is, any IPv6 Extension headers that need be processed only by the final destination node(s), plus the upper-layer header and data (that is, the Destination Options IPv6 Extension header, the TCP header and its payload in our example).

 

But let's focus on Next Header values of the IPv6 Fragment Extension Headers. Regarding fragmentation, according to RFC 2460, page 20, each fragment packet (among else) is composed of an IPv6 Fragment Extension header containing “the Next Header value that identifies the first header of the Fragmentable Part of the original packet”. So, the Next Header values of the IPv6 Fragment Extension headers of ALL fragments should be the same and equal to the header value of the first header (IPv6 Extension header or layer-4) of the fragmentable part. To clarify it farther, RFC 2460 at page 21 suggests that the Unfragmentable Part of the reassembled packet consists of of all headers up to, but not including, the Fragment header of the first fragment packet (that is, the packet whose Fragment Offset is zero), with the following (among else) change: “The Next Header field of the last header of the Unfragmentable Part is obtained from the Next Header field of the first fragment's Fragment header.” And, if there is a doubt, to clarify the situation, RFC 2460 at page 22 recommends that “The following conditions are not expected to occur, but are not considered errors if they do: ... <snipped for brevity>... 2) The Next Header values in the Fragment headers of different fragments of the same original packet may differ. Only the value from the Offset zero fragment packet is used for reassembly. ”.

 

I suppose that the situation now is crystal clear. No matter what the Next Header values of the IPv6 Fragment Extension headers used in the fragments are, it is only the Next Header value of the IPv6 Fragment Extension header whose offset is zero (0) to be used as the Next Header value of the last header of the unfragmentable part. Yet another potential ambiguity introduced by our beloved IPv6 RFCs. But, protocol ambiguities, always ring the same bell: "IDPS Evasion".

 

Let's see an example: Let's assume that the original packet that needs to be fragmented is the following:

 

 

 

 

 

 

 

 

Note: Off course, you can change, add or even remove one of the used IPv6 Extension headers, if you wish. Now, let's assume that the fragmentable part is the following:

 

 

 

 

 

 

 

 

According to what have been described so far by RFC 2460, the aforementioned packet should be fragmented as following:

 

1st fragment:

 

 

 

 

 

 

 

and the 2nd fragment:

 

 

 

 

 

 

 

 

Please, note the Next Header values of the IPv6 Fragment Extension headers, as recommended by RFC 2460.

 

Now, what if the Next Header value of the second fragment points to the layer-4 header, that is, what if the second fragment is like the following:

 

 

 

 

 

 

 

In this case, the IPv6 Fragment Extension header of the second fragment “points to” the layer-4 protocol, which is TCP in our example, the header value of which is 6. As described above, according to the RFC 2460 such a case should not occur but is not considered as an error if it does :-)

 

Well, by testing such packets at the RISC lab together with the ERNW guys, we found out that:

 

1. Most of the popular Operating Systems (Windows, Linux, OpenBSD) accept such fragmented datagrams, as they should actually, according to RFC 2460.

2. Tipping Point IDPS (TOS Tipping Point, Package 3.6.1.4036 and digital vaccine 3.2.0.8530)  misinterprets such fragments and lets them pass through even if you have explicitly defined not to do so (again, more details on the tests that we run, the used configuration, etc. can be found here).

3. The above combination results in a layer-3 evasion of the Tipping Point IDPS device, which means that you can actually launch any kind of attack (from port scanning to SQLi) while remaining undetected.

 

Here, I should note that:

1. Tipping Point IDPS is not the only IDPS device that it has been found out to be vulnerable to the aforementioned attack, or a variation of it.

2. The specific vendor reacted rapidly and has already patched the described vulnerability (please, check their web site for available patches).

 

Is this the end? Well, I am afraid not ;-) IPv6 Extension Headers are a mess, indeed. More will follow, so, stay tuned!

0 Comments

Tue

25

Mar

2014

Researching IPv6 Security Capabilities (RISC) of Commercial Security Devices

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.

0 Comments