Tag: IPv6

A couple of hours ago Christopher (Werny) and I gave this presentation at the Heise IPv6-Kongress, which overall was a quite interesting and well-organized event bringing together a number of practitioners from the field. While yesterday’s talks were dominated by a certain euphoria and optimistic pioneer spirit, the second day featured some security talks which induced slight shadows to the brave new world of IPv6 ;-). I particularly enjoyed meeting Eric Vyncke from Cisco (one of the two authors of this great book) and Marc “van Hauser” Heuse who released a new version of the THC-IPV6 tool set today. We had some fruitful discussions and we took the opportunity to test some of his newly implemented attacks against “RA Guard” running on a 4948E Chris and I had brought for a demo within our talk. Unfortunately – or fortunately in terms of a “from theory to reality” approach – I have to say that Marc found a quite clever way to circumvent RA Guard by putting the actual “RA payload” into a second frame following a first one mostly containing a “long & empty” destination option (after a fragmentation header pointing to the mentioned second one). To get an idea pls see these screenshots from Wireshark.

This actually completely defeats (the current implementation of) RA Guard which means that the victim machine received a whole lot of router advertisments…

Eric who gave an excellent talk on his own (mostly covering defense techniques but, amongst others, describing some interesting attacks against tunnel technologies, which btw reminds me I still owe you a blogpost on those… trust me: it’s not forgotten ;-)) stated that this specific type of attack could be mitigated by using an ACL containing sth along the lines of

deny ip any any undetermined-transport

[which is supposed to match any IPv6 packet where the upper-layer protocol cannot be determined].

We (Christopher and I) weren’t even aware of that keyword and we did not yet have an opportunity to test its effectiveness. Still there’s some immediate lessons to be learned from those hours in Frankfurt:

a) in the field of IPv6 security one can learn something new every day 😉

b) there’s still so much “uncovered space” in the IPv6 (security) world that we’ll certainly see yet-unknown types of attacks in the next years.

c) Marc is a really smart guy (which prompted me inviting him to speak at next year’s Troopers ;-))

d) Going with ACLs on “access layer”/customer/subscriber facing ports might be the better approach than just using RA Guard. (on a related note: some Cisco guy I talked to was very sceptical that RA Guard will ever be available on 2900 or 3500 series switches).

Most probably this ([1], [2], [3]) little sequence of IPv6 related posts will be continued soon (but not before we’ve finished the update of the “Attacking 3G and 4G networks” talk to be given at HITB Amsterdam next Friday ;-)).

Have a great weekend everybody

Enno

netsh int ipv6 set int [index] routerdiscovery=disabled

Hi everybody,

this post is the sequel of this one on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948” only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).

Well… we’ll certainly find some useful function for that device – and I just initiated the acquisition of a 4948E – but I was just eager to get my hands on the practical use and implications of RA guard. Looking at the Cisco Feature Navigator for “IPv6 Basic RA Guard” it seems that it’s still the same platforms supporting it as eight weeks ago, so there was only one option left: get one of our Cat 65Ks from the basement and perform the testing with it.

Given ERNW’s strong emphasis on sports pretty much immediately some kind-of “strong man contest” evolved going like “who can lift and carry the device without further assistance”

so we had quite some fun just putting the box into operation.

[for those interested we can provide the number and nature of modules installed at the time of that contest ;-)]

Ok, back to the technical side of things. Here’s what we did:

Step 1) Perform RA based attacks with “RA Guard” being absent.

For that purpose we used Van Hauser’s THC-IPV6 attack suite (which can be found here) and performed two specific attacks.

1a) Use

fake_router6 eth0 2001:db8:dead:beef::/64

to send spoofed RAs which resulted in an additional prefix and associated default gateway being learned on the victim system (default install of current MS Windows).

It should be noted that the additional (“spoofed”) default gateway had a better (= lower) metric in the routing table.

1b) Use

flood_router6 eth0

to send arbitrary spoofed router advertisements (with the eventual purpose of a DoS condition). This worked equally well. Right after starting the attack the CPU load of the attacked system ‒ and for that matter, the load of other systems on the local link as well ‒ went to 100% (and stayed there for hours after stopping the emanation of packets on the attacker’s host).

[you might notice that this is not the “oldest and weakest laptop we took from our lab shelf”…]

In short: both RA based attacks we tried worked like a charm.

So this is absolutely something every security responsible of a IPv6 enabled network should be concerned about…

Step2: put lab device into action, enable RA guard and check if it helps.

At the time of our testing the box was running

Cisco IOS Software, s3223_rp Software (s3223_rp-IPBASEK9-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)

[which, btw, “silently ignores”  any WS-X6248-RJ-45 modules present in the box. Of course, I’m aware that all of you valued readers always carefully read the release notes of this (or other) images before deploying them…]

We then enabled RA guard on the access-ports to-be by

Router(config)#int range f1/24 – 36

Router(config-if-range)#switchport

Router(config-if-range)#switchport mode access

Router(config-if-range)#ipv6 nd raguard

and performed the attacks again.

Without success! Seemingly the box efficiently (and silently) discarded all RA packets arriving on those ports.

So we can certainly state that RA guard fully performs as expected. One minor annoyance we noticed: there seems no log message of any kind while the attack is in progress.

However, earlier – when performing step 1a – we had noticed sth like this on the router legitimately serving the local network with RAs:

Thus there might still be a way to detect RA based attacks. It’s just not on the box providing protection from them but on another one.

If you want to see these attacks (and the – quite simple – configuration of RA guard) in practice you can do so either at our workshop on “IPv6 security in LANs” at Troopers or at the Heise IPv6 Kongress in May. At both occasions we’ll demonstrate this stuff.

We think that RA guard is pretty much the only way to protect against RA based attacks in an operationally feasible way (as opposed to, say, filtering ICMP type 134 by means of port based or VLAN ACLs).

To mitigate the risk of “RA interference” caused by potentially misconfigured systems (e.g. Windows systems running 6-to-4 with a public IPv4 address and Internet Connection Sharing enabled; more on this in a future post on IPv6 tunnel technologies) or by systems “accidentally inserted into the local network” (employee connecting SOHO DSL router. which, again, certainly never happens in your network…),  there might be another configuration tweak that could help. The standards track RFC 4191 on Default Router Preferences and More-Specific Routes introduced the concept of a preference assigned to router advertisements distributed by routers on the local link.

For that purpose the format of RA messages is extended and two of the previously unused bits within the byte containing the flags are used for a “Prf” (Default Router Preference) value.

The configuration is quite simple (on Cisco routers where the feature was introduced in IOS Version 12.4(2)T) and goes like this:

Router(config)# interface f0/1

Router(config-if)# ipv6 nd router-preference {high | medium | low}

Hosts receiving RAs tagged with a high preference flag will prefer them over RA messages emitted with the default value (“medium”). We’ll play around with this in a more detailed fashion at some occasion and keep you posted. In the interim you might look  here to get some background on the way router preference works.

The next post of our series is planned to cover the (in the current Windows world) ever-present tunnel technologies and their security implications.

Have a great weekend everybody,

Enno

Hi,

at first a happy new year to our loyal readers (and, of course, to everybody else too ;-)! We hope you all had some pleasant transition times, not suffering from bad hangovers after 27C3 or sth 😉

Things are heating up for Troopers and in the course of that we started putting together the slides for the workshops (I’m delighted that Flo told me today there’s already quite a number of bookings for the workshops…). I myself will give the “IPv6 Security in LANs” workshop, together with Christopher. The workshop preparation will be accompanied by a series of blogposts with three main areas to be covered:

– IPv6 behavior in the LAN, its underlying trust model and subsequent attacks (all the attacks centered around ND, RA etc.).
– tunnel technologies and their inherent risks.
– risks associated with IPv6 addressing (reachability of internal systems due to route leakage, problems related with privacy extensions etc.).
Pls note that we assume that the reader already disposes of some knowledge of IPv6 inner workings so we’re not going to cover protocol basics here.
[at some point we might provide a list of books we regard valuable for the topic though]

  
To get some inspiration and an update on current attacks I just watched the youtube video of Marc Heuse’s (aka Van Hauser from THC) talk at 27C3 on “Recent advances in IPv6 insecurities”. Impressing stuff! I’d say: a must see for everybody involved in IPv6 security.
The Q+A session will serve as a starting point to today’s post.
The second question (at about 44:55 in the youtube video) comes from a guy asking for “mitigation techniques”. Marc’s answer is “vendor updates”.
While this is certainly correct to some degree I’d like to add that there are – depending on the network infrastructure deployed – fairly simple ways to mitigate all the nasty “spoofed RA”, “RA flooding” etc. stuff.

To illustrate those let’s take ERNW’s “Seven Sisters of Network Security” approach which describes fundamental guidelines for infrastructure security that can be applied regardless of the technology/-ies in question (or even regardless of the network context. They work for any kind of complex system, be it a network, a building, a production plant etc.).

a) Sister no. 1: “Access Control” (keep the threat out of the overall system). Obviously keeping an attacker who tries to perform all those awful IPv6 based things out of your network at all (e.g. by using 802.1x) would be elegant and nice. Still let’s assume for the moment that the approach of access control is, for whatever reason, not available.

b) Sister no. 2: “Isolation” (limit the assets’ visibility/reachability with regard to the threat).

The isolation principle can be applied in two ways. First it should be obvious that, given the link-local nature of RAs, most of RA/ND related attacks can only be performed on the local link (“IP subnet” in IPv4 lingo) so putting systems-to-be-protected in different segments than those where attacks can be expected (e.g. due to type of users or systems located in them) would be a first step. So, once more, proper network segmentation can be your friend. This can’t be stated often enough! Unfortunately this isolation approach isn’t present in many environments and can’t be implemented easily either.

Second – and this (finally ;-)) is the main point of this post – on an abstract level router advertisments are kind-of sensitive traffic that should not originate from “the untrusted access domain” but only from “trusted infrastructure devices”. So preventing “the access domain” from injecting RAs and limiting RA originators to some trusted entities (e.g. identified by the network ports they’re connected to) would be “the architectural approach”. Which is exactly what the “Router Advertisment [RA] Guard” feature does.
RA Guard, currently described (note that I’m not writing “specified”) in this IETF draft (after all available as a “08 version” which means there’s some momentum in the process) works quite similarly to other Layer 2 protection mechanisms (for example “DHCP snooping”) available on many access switches nowadays: “do not accept a certain type of [infrastructure protocol] packets on certain ports”. In our context this would mean “do not accept RAs on all ports except those where the trusted L3 devices are connected”. Usually this type of protection mechanisms requires (only!) one extra line of config added to your “secured port configuration templates” – that all of you use, don’t you? 😉 – which in the case of Cisco devices would be “ipv6 nd raguard” (see this doc for more details).

Unfortunately, in the Cisco space (haven’t checked other vendors so far) RA guard seems currently only available on recent images for either Cat65K with Sup 720/Sup-32 and 4500/4900 series devices. We have a Cat65 with Sup-32 in our lab but I certainly don’t want to use this for the workshop (hint: being in the same room as a running Cat65 and trying to understand what the instructor tells you might instantly become tedious, for you… or the instructor ;-)).
So, for today, I can only state that based on my “paper understanding” of the way RA guard works, this will certainly be a good (means: operationally feasible) way of addressing a number of problems related with IPv6’s trust model in LANs. I just bought a 4948 on ebay and will start playing around with the feature once it arrives and share my thoughts on it here. I’m sure that RA guard will creep into other images soon as well so I’d surprised if it wouldn’t be present on, say, 3750s in the near future.

c) For completeness’ sake it should be noted that going with sister no. 3 “Restriction” (restrict/filter traffic between threat and asset) would be another option.
Filtering ICMP message 134 by port based or VLAN ACLs _could_ be another potential mitigation approach. Albeit one with much more operational cost than going with RA guard. So, if available, pls use RA guard and not the filtering approach. And pls don’t use both (at least not on the same devices). Why? See this post…

d) Again, for completeness’ sake I’d like to add that sister no. 4 “Use of Cryptography” could come into play as well, by using SEND (SEcure Neighbor Discovery as of RFC 3971). Personally I do not expect many environments to use SEND at all due to the large crypto and subsequent operational overhead.
Remember: the initial architecture of IPv6 was developed in the 90s where the naive thinking of “LANs are trusted and crypto can solve all problems if there are any” was still prevalent and (practically) nobody considered operational effort as a main driver (or “inhibitor”).

Will keep you updated once the 4948 “shows up” and I can perform some practical testing.

thanks

Enno