TROOPERS12 Conference
Thank you for attending another edition of your premium ITSec event!
Slides to be found in the archive.
Twitter
PostsArchive for January 2011
Just a quick announcement: The slides of “Attacking 3G and 4G mobile telecommunications networks” are available now. Tools and video to follow soon.
Head over to http://www.ustream.tv/user/shmoocon2011/shows to enjoy the last talks of ShmooCon 2011 live.
Have a great Sunday!
Florian
]Hi,
just a short, somewhat non-technical, post today: I really like this response Ross Anderson gave to the “UK Cards Association” asking Cambridge University for taking offline a thesis of one of their students. It (the letter) pretty much summarizes how security research should be treated and backed by those interested in a more secure world we live in.
On a personal note I’d like to add that Ross’ main volume “Security Engineering: A Guide to Building Dependable Distributed Systems”, initially published in 2001 and updated in the interim with a second edition in 2008, has been the most influential security book for me on my long way in the infosec space (which started back in 1997, with some workshops on firewalls I gave for IT auditors). If I could take only one infosec book to a lonely island, it would be this one.
[not sure which one to take if I could only take one book at all ... maybe Thomas Mann's "Doktor Faustus"... will get back to this once I've figured an answer ]
Back in a few days with the next part on IPv6, have a good one 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