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,
IPv6 introduces a lot of new features and consequently, a lot of new capabilities. Obviously, the most significant of them is the huge address space that it offers. However, this is not the only one. IPv6 also introduces the use of the IPv6 Extension Headers. The IPv6 header has been considerably simplified in comparison with IPv4 one. On the other hand, the IPv6 Extension Headers, not only do the “job” of most of the fields which were removed from the main header, but, additionally, they add many more. However, any new “technology” creates new attack opportunities and a “new” protocol, such as IPv6 could not be an exception, especially since its design and implementation is more complicated than it’s predecessor.
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”.
It has been a year since fragmentation attacks in IPv6 were last examined publicly (in Black Hat Europe 2012). Issues well known from the IPv4 era appeared again in IPv6. Surprisingly enough, some of the most popular Operating Systems (OS), included ones considered “secure”, were proven to be vulnerable to such attacks, although fragmentation overlapping is strictly forbidden in IPv6 since 2009 (RFC5722). Some other OS, although in a better shape, still appeared to have some issues in specific cases.
But a year has already passed since then and the vendors should have fixed these issues now; or not? Definitely, a significant progress (in some cases) has been made but, is this enough? In the IPv6 Security Summit that will take place during Troopers13, in the “Fragmentation Overlapping Attacks Against IPv6: One Year Later” presentation, various fragmentation overlapping scenarios will be tested to examine if such attacks can still be successful or not. Detailed results of extensive tests will be presented and any non-compliant behaviors will be further discussed regarding the potential security implications.
Last week I read about the new networking features of the integrated vSwitch of Hyper-V 3.0. I was quite surprised that RA Guard will be natively supported and was curious about implementation and functionality. If you don’t know how RA Guard works, I recommend reading our previous blog posts here, here, here, here and here, or have a look at our workshop at Troopers12.
I downloaded Windows Server 2012 RC to do some practical testing. Since my girlfriend was working the whole weekend, I had plenty of time to play around with all that stuff without risking trouble 😉
I installed the RC and Hyper-V role on one of our lab systems.
The basic setup looks as follows:
Two VMs were installed (one Windows 7 box and one Backtrack 5) and connected to the same vSwitch and were part of the same layer-2 domain (as RAs only matter in a layer-2 domain). A layer-3 switch was the legitimate router sending RAs so that the Windows 7 box configured appropriately. All tests were done with the THC-IPv6 suite from Marc Heuse. The IPv6 configuration of the Windows 7 box looks as follows:
Before starting my tests, I wanted to verify that all is working correctly. So I began sending rogue RAs from a Backtrack VM.
Nothing special here, the Windows 7 box received the RA and configured an IPv6 address from the supplied prefix.
After the verification succeeded I enabled RA Guard in the settings of the network adapter on the Backtrack VM.
To structure the tests a little bit, I created a small test plan on what and how I wanted to test:
Test 1 – Sending Rogue RA’s with RA Guard enabled
The first test included sending of (non-fragmented) RAs with RA Guard enabled on the VM.
Test 1 – Results
Again I started to send Rogue RAs like I already did before.
As I expected, the RAs got filtered by the vSwitch and are not seen on the Windows 7 box (only the legitimate RAs from fe80::1).
Consequently, the IPv6 configuration did not change.
Test 1.1 – Sending Fragmented Rogue RAs with RA Guard enabled
In the next test I wanted to figure out how the vSwitch handles fragmented RAs with a ICMPv6 header being only present in the second fragment.
Test 1.1 – Results
I started to send fragmented RAs with an additional Destination Header to force fragmentation.
Interestingly, the first fragment with the destination header passed the vSwitch and arrived at the Windows 7 box. However, the second fragment with the ICMPv6 header got filtered by the vSwitch. You can see the legitimate RAs in between the fragments.
Like in test before, the IPv6 configuration of the client did not change and the received fragment did not have any impact on the CPU load of the box.
Interim Conclusion
The RA Guard implementation of the vSwitch in Hyper-V reliably filters router advertisements from a VM whether or not they are fragmented. This is good thing. Unfortunately I couldn’t find any entries in the event viewer (or elsewhere) indicating that a VM started to send RAs. This just hides the problem without really addressing it. As an administrator of a virtualized environment I would want to know when a VM starts to send RAs, in order to take appropriate measures.
Test 2 – Flooding RA’s with RA Guard Enabled
In the next test, I wanted to find out how the vSwitch (or better the physical Hypervisor) behaves when a lot of RAs are generated by a VM. For this test, the flood_router 6 module was used.
I started to flood RAs from the Backtrack VM.
The RAs were filtered by the vSwitch and didn’t reach the Windows 7 Box. I got the same result in Wireshark as in the test before. Only the legitimate RAs were seen by the VMs.
The more interesting thing I noticed, was the CPU load of the physical Hypervisor jumping to around 25% (occupying a whole CPU ) as soon as I started flooding.
btw: That’s how the new task manager looks like in Windows Server 2012
I started wondering: If one VM flooding RAs can produces 25% CPU load, what happens if more than one VM starts to flood RAs? Let’s find out…
… with three additional instances of the Backtrack VM for a total of four.
I had some trouble getting all 4 working simultaneously because the flood_router6 module exited quite a few times (which is fixed in version 1.9). That’s why you see those variations in the CPU load. If looking at the point where the CPU load was nearly zero, you can see how it increases in 25% steps, based on how many VMs started to flood RAs. However, even with four VMs flooding in parallel the CPU load stalled at around 75%. But this may be only a matter of how many VMs are flooding RAs.
Test 2.1 – Flooding RA’s with fragmented RA Guard Enabled
As we now knew about the impact on the Hypervisor when one or more VMs start to flood RAs, I wanted to know if anything changes for fragmented RAs.
I started to flood fragmented RAs with an additional Destination Header to see what happens.
The result equals as for Rogue RAs. The first fragment hit the Windows 7 box, but the second fragment got filtered by the vSwitch.
The received fragments did not have any impact on the CPU load of the Windows 7 box.
As before, I was mostly interested in the Hypervisor’s behavior.
Interestingly, the CPU load doubles as soon as fragmented RAs are sent by one VM.
Increasing the VM count to four again at this point appears to be obvious.
The CPU load increases to 90% on average, which is quite huge for just four VMs sending a lot of (fragmented) RAs. Other VMs are not directly affected from the RAs. However, a Hypervisor running out of resources is never a good thing.
Final Conclusion –Well said Mister but does this really matter?
I think it does, because Windows Server 2012 is positioned as “cloud operating system”. As a cloud provider, you typically want to give your customers the ability to spin up as many virtual machines as they like. When a malicious customer can exhaust the Hypervisor’s resources, normal customers will be affected as well. In particular if exhausting resources can be done so easily.
Be aware that these tests were done with the Release Candidate, and it might be possible that the final version of Windows Server 2012 behaves differently. We have to wait and see ;). I will definitely run the tests again when Windows Server 2012 ships.
So what can we do to address this issue? Unfortunately I don’t have a definite answer as of right now. Without knowing the codebase it’s hard to say how this behavior could be prevented or improved. So far it’s up the vendor to address this issue and customers (or pentester’s) duty to point at it…
One thing Microsoft could do is just to disconnect the virtual NIC if too many RAs were send from a VM in order to protect the resources of the Hypervisor.
As in 2011 we really liked the conference; there was a number of interesting talks and we met quite some fellows from the IPv6 security space. Btw: we plan to organize a dedicated IPv6 security summit in late 2012 (probably on 6th and 7th of November) in Heidelberg, similar to the Telco Sec Day at Troopers. We’ll annouce details as for this one in some weeks.
TROOPERS12 came to an end last week on Friday; needless to say it was an awesome event. 😉
The first two days offered workshops on various topics. On Monday Enno, Marc “Van Hauser” Heuse and I gave a one day workshop on “Advanced IPv6 Security”. I think attendees as well as trainers had a real good time during and after the workshop fiddling around with IPv6. Especially Marc had quite some fun as he discovered that we provided “global” IPv6 Connectivity for the conference network, and according to one of his tweets, TROOPERS12 was the first security conference he visited, offering this kind of connectivity.
So back to the topic
Our last posts on IPv6 Security go back to the first half of 2011. If you haven’t read them already, now it’s a good time to do so. You can find them here, here, here and here.
In the last post of the series Enno discussed how RA-Guard can be circumvented with clever use of extension headers. As a short reminder, the packet dump looks like this.
The Information of the upper-layer protocol is only present in the second fragment, so RA Guard does not kick in.
As we found out on the Heise IPv6 Kongress last year, this issue can be mitigated with the following parameter in an IPv6 ACL.
deny ipv6 any any undetermined-transport
As a reminder, this parameter drops all IPv6 packets where the upper-layer protocol information cannot be determined.
After the workshop was officially over, Marc and I played a little bit with this ACL Parameter to see if it is working as intended. So I configured the following IPv6 ACL on our beautiful Cisco 4948E:
4948E(config)#ipv6 access-list IPv6
4948E(config-ipv6-acl)#deny ipv6 any any undetermined-transport
4948E(config-ipv6-acl)#permit ipv6 any any
4948E(config)#interface g1/19
4948E(config-if)#ipv6 traffic-filter IPv6 in
We started the attack again with the following parameter:
Apparently nothing happened with my (IPv6 enabled) laptop (which is a good thing ;))
The corresponding packet dump looked quite unspectacular:
Only the STP packets could be seen, and the flooded router advertisements were dropped by the Switch.
So could this parameter solve the issue with the whole RA mess?
Unfortunately the answer is no. The ACL parameter does mitigate the issue with the fragmented router advertisement. However, the ACL parameter can be circumvented by using overlapping fragments. Unfortunately we couldn’t test this scenario because this wasn’t yet implemented in the THC Tool Suite, but this is just a matter of time…
The IPv6 Packet basically looks like this:
Fragment 1:
IPv6 Header
Fragmentation Header
Destination Header (8 bytes)
ICMPv6 with Echo Request
Fragment 2:
IPv6 Header
Fragmentation Header with offset == 1 (equals position of 8th byte ==
start of Echo Request in first fragment)
ICMPv6 with RA
In this case it depends on the operating system whether or not the packet is discarded when overlapping fragments are detected. RFC 5722 is very specific on how these should be handled:
“When reassembling an IPv6 datagram, if one or more its
constituent fragments is determined to be an overlapping
fragment,the entire datagram (and any constituent fragments,
including those not yet received) MUST be silently discarded.”
So it is up to the operating system to implement this behavior. We’ll see how things work out 😉
If you’re interested in more IPv6 issues, or simply wanna chat about this topic, meet Enno and me again at the Heise IPv6 Kongress this year in Frankfurt, where we will give a talk on IPv6 as well.
