on the [ipv6-ops] mailing list currently there’s some discussion about RA guard support on switches from different vendors.
Stefan, one of our students (btw: working on a topic similar to this session), quickly put together a preliminary list, based on publicly available information (read: the WWW ;-)). Some of you may find this useful; it can be found here. Furthermore on the list this link was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).
If anyone of you has better/more information pls feel free to share by leaving a comment. The IPv6 security comment will thank you for that đ
just to let you know that all presentations from this year’s TelcoSecDay are published in the interim. (Harald [Welte] couldn’t participate as in the morning of that day FRA airport was closed on short notice).
Just a quick update here: Ivan (who gave the magnificent Virtual Firewalls talk at Troopers recently) blogged about this and some guy added some feedback from an environment with Cisco FEX and “one of the server guys start[ing] a Citrix Netscaler” ;-). See the second comment to his post.
This shows, once more, that the dependencies of various technologies (and what they are used for) must be well understood in cloud/virtualized environments. Complexity … but who do we tell. Y’ all know that, right?
I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the North American IPv6 Summit next week) about the feasibility of the “undetermined-transport” keyword in PACLs on Cisco 3560 switches (here running  IOS 15.0(2)SE). Actually there’s some kind-of funny behavior as for it on that platform (and there’s even some Cisco documentation stating it’s not supported). Let’s have a look, and start with a quick refresher.
Rogue router advertisements pose a significant security and network stability risk in IPv6 networks. That’s why there’s a security feature implemented on certain switches which is called “RA Guard” (see also here). Unfortunately (at least Cisco’s current implementation of) RA Guard can easily be circumvented, e.g. by using the following command from the THC IPV6 attack toolkit:
We had a great day today at the Troopers IPv6 Security Summit. Good conversations, quite some technical discussion and a prevailing overall will to improve actual IPv6 network security.
Here are the slides of Antonios Atlasis’ great talk on extension headers and these are some of his accompanying Python/Scapy scripts. My own presentation on high secure IPv6 networks can be found here. The slides of the real-world capabilities workshop will not be published yet as we first have to discuss some stuff with a vendor.
Looking forward to tomorrow, have a great evening everybody
Recently there has been quite some discussion about so-called neighbor cache exhaustion (“NCE”) attacks in the IPv6 world. This is Jeff Wheeler’s “classic paper” on the subject, my kind-of personal networking guru Ivan Pepelnjakblogged about it back some time, here‘s a related discussion on the IPv6 hackers mailing list and in March 2012 (only three months after the respective IETF draft’s version 0 was released) the RFC 6583 was published, covering various protection strategies.
In the run-up to this workshop I’ll give at the Troopers IPv6 Security Summit next week I decided to build a small lab to have a closer look at NCE, in order to be able to express reasonable statements during the workshop ;-).
This is the first part of a (presumably two part) series of blog posts presenting the lab results and potential mitigation approaches. In this first part I’ll mostly focus on the actual attacks & lab testing performed. I won’t explain the basic idea behind NCE, you might look at the above sources (in particular Jeff Wheeler’s presentation) to understand the way it is supposed to work and to cause harm.
Actually the lab setup was quite simple. The lab was composed of a layer 3 device (mainly a Cisco 1921 router running an IOS 15.1(4)M3 image, but this got temporarily replaced by others, see below) connecting two segments, a “good” one hosting two physical systems (e.g. to be considered members of a fictional DMZ) and a “bad” segment with an attacker system. Essentially the only requirement was that all connections (attacker’s system’s NIC to switch & switch to all router interfaces involved) were at Gbit speed to simulate an attacker coming in from a high speed Internet link. [yes, I’m well aware that a 1921 can’t really push traffic at Gbit speed ;-)]
Besides the necessary basic IPv6 addressing config, the router was mostly in default state, so no tweaking of any parameters had taken place.
Marc Heuse – who happens to give this workshop at the Troopers IPv6 Security Summit next week – just sent this email (subject: “Remote system freeze thanks to Kaspersky Internet Security 2013”) to the IPv6 hackers mailing list, describing how a system running a certain flavor of Kaspersky security products can be remotely frozen when receiving IPv6 packets with a specific combination of extension headers and fragmentation (which in turn can be easily generated by his IPv6 protocol attack suite).
This illustrates once more the huge security problems related to IPv6 extension headers and IPv6 fragmentation and in particular to the combination of those two. Antonios Atlasis will discuss those in detail at the event (see his announcements here and here). It would be really helpful if major security products had some simple global properties/command line parameters/checkboxes like “drop all fragmented IPv6 packets”, “drop all IPv6 packets with extension headers” (ok, maybe “drop all IPv6 with multiple extension headers”; besides HBH in MLD packets – which shouldn’t traverse L3 hops – we don’t see too much ext headers in production networks anyway, as of early 2013) or at least “drop all packets with a combination of fragmentation and ext headers other than the fragmentation header”. But this will probably need another some years to show up and unfortunately we’ll probably see such problems still for a very long time…
Again, you should see Antonios’ presentations on this stuff (I had the chance to look at them already, it’s great research with scary results). For those of you who can’t join us: they’ll be made available for download after the conference.
Looking forward to an active discussion of these topics at the IPv6 Sec Summit,
Many of you have probably seen the public media coverage (e.g. [1], [2]) of  Mandiant’s latest report on APT.
Just to let you know: Trooper‘s traditional panel discussion on the first day will be on APT this year. So if you want to discuss the topic with other practitioners from the field, join us there.
Here’s a number of updates as for upcoming TROOPERS13.
The preliminary agenda for this year’s TelcoSecDay can be found here.
Here‘s the (again: preliminary) agenda of the IPv6 Security Summit.
Last, but not least we’ve included another four talks in the main conference:
======
Sergey Bratus & Travis Goodspeed:Â You wouldnât share a syringe. Would you share a USB port?
Synopsis: Previous work has shown that a USB port left unattended may be subject to pwnage via insertion of a device that types into your command shell (e.g. here). Impressive attack payloads have been delivered over USB to jailbreak PS3 and a âsmart TVâ. Not surprisingly, USB stacks started incorporating defenses such as device registration, USB firewalls, and other protective kits. But do these protective measures go far enough to let you safely plug in a strange thumb drive into your laptopâs USB port?
We demonstrate that the scope of the OS code manipulation feasible through a USB port is much broader than could be expected. USB stack abuse is not limited to emulating HID keyboards or a few exotic devices â it is a clear and present danger throughout the USB software stack and can reach into any part of the operating system kernel and driver code. We show a simple development environment that is capable of emulating any USB device to engage whatever software on the host computer is meant to interact with such devices â and break any and all of the assumptions made by such software, leading to pwnage. In a nutshell, sharing a USB port belongs in the past â just as the era of downloading arbitrary executables and other Internet âfree loveâ.
We’re very happy to announce the third round of Troopers 2013 talks today (first round here, second here).
So much quality stuff… it seems to get (ever) better every year ;-).
Here we go:
==================
Michael Ossmann & Dominic Spill: Introducing Daisho â monitoring multiple communication technologies at the physical layer.
Synopsis: Most communications media can be monitored and debugged at various levels of the stack, but we believe that it is most important to examine them at the physical layer. From there, the security of every level can be investigated and tested. The task of monitoring physical layer communications has become increasingly difficult as we try to squeeze more and more bandwidth out of our links. A passive tapping circuit can be used to monitor a 100BASE-TX connections, but no such circuit exists for 1000BASE-T networks.
Our solution to this problem is Project Daisho; an open source hardware and software project to build a device that can monitor high speed communication links and pass all of the data back to a host system for analysis. Daisho will include a modular, high bandwidth design that can be extended to monitor future technologies. The project will also produce the first open source USB 3.0 FPGA core, bringing high speed data transfer to any projects that build on the open platform.
As a proof of concept at this early stage, we will demonstrate monitoring of a low bandwidth RS-232 connection using our first round of hardware and discuss the challenges involved with the high speed targets such as 1000BASE-T and USB 3.0 that we will take on later this year.
Bios: Michael Ossmann is known for his experience with radio communications technology and open source hardware design, having produced both the Ubertooth and HackRF as well as regularly teaching workshops on software defined radio. He has spoken about his work with software defined radio and Bluetooth at Troopers, Black Hat, DEF CON, ToorCon, ShmooCon and more.
Dominic Spill has been building a Bluetooth packet sniffer since 2007; last year he took over as lead developer for the Ubertooth and has recently begun working with Michael on Daisho. He has previously presented his Bluetooth work at DEF CON, ShmooCon, USENIX WOOT, and Kiwicon.
Both speakers have a passion for building open source tools to allow curious people to examine the technologies and protocols that we use to communicate.