This is a guest post from Antonios Atlasis.
On Thursday the 20th Enno, Jayson and I had the pleasure to present our latest research results regarding MLD at Deepsec 2014, both from vendors’ implementation perspective as well as regarding protocol design flaws (some preliminary results as well as our testing methodology were discussed here and here).
For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of IPv6, is to inform routers about the presence of nodes which are interested in receiving specific multicast traffic (RFC 2710). The newer version of MLD, MLDv2 adds the ability for source address selection (RFC 3810).
Now, before we proceed with our results, let’s briefly discuss some facts and myths about MLD.
- Fact No 1: solicited-node multicast addresses are used during the Neighbor Discovery (ND) process (RFC 4861).
- Fact No 2: RFCs “imply” (!?) that MLD is required for joining solicited-node multicast addresses groups and hence, for the ND process (RFC 4861, paragraph 7.2.1: “joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols”).
- Fact No 3: MLD Reports are the very first messages sent by most of the popular Operating Systems (OS) during the booting process, even before a link-local address is configured (see here).
So, it seems that MLD is a significant protocol for the core IPv6 operation of ND, right?
However, as it was shown here, if you stop MLD messages (by blocking incoming and outgoing MLD messages using a host based firewall), the ND process still takes place effectively. Moreover, in OpenBSD the ND process is successfully completed without even enabling MLD.
For those who may think that MLD is/will be required if/when MLD Snooping is enabled, our tests at a Cisco Catalyst 2960-S IOS 15.2(1)E3 showed that when you enable MLD Snooping, solicited-node multicast addresses are still broadcasted (maybe for avoiding deliberate/accidental overflow of the table that registers multicast-groups, or to avoid breaking ND due to bugs like this?).
Thus, it seems that the assumption of requiring MLD in IPv6 environments for the ND process, is actually a myth.
OK, you may wonder what’s the big deal if MLD is not that important for ND or any other IPv6 core functionality and it still comes pre-enabled? Well, the problem is that it raises some security concerns, like:
- It can be used to identify very easily and even passively the nodes in a link-local network, and even to identify OS families (Windows, Linux, FreeBSD, due to the fact that each one of them joins some different multicast groups) without even sending a single packet.
- Not all OSs respect the “Hop-Limit=1” security precaution.
- If you flood Windows systems in a virtualised environment with MLDv1 Queries, their CPU is overloaded, reaching 100% and making them unusable (yes, there are easier ways to achieve this, but this is yet another option).You can cause the the memory depletion of and/or overload the CPU of routers like Cisco 1921, IOS15.4(3)M, or even Cisco ASR 1002 by flooding them with MLD Reports and make them actually unusable (this is bad, we think).
Finally, no matter if MLD Snooping is enabled or not, there are two different MLD attack variations that can be used to stop easily and effectively a multicast application transferred over IPv6. If this doesn’t sound very bad, can you imagine this happening during a share-holders video-conference of an enterprise? This attacks can be achieved by using “properly” and in a combined way some MLD functionalities which are officially allowed by the RFCs. These can be summarised to the following:
- Taking over the Querier role.
- Interacting in an one-by-one way with nodes (routers and/or hosts) with MLD messages (Queries/Reports/Done) by using ff02::2 or ff02::16 as a destination address for the routers and the global or link-local unicast address for any node (routers/hosts).
- By forcing downgrade to MLDv1, if required.
At Deepsec we demonstrated live the attack against one of the routers, which turned to be that destructive to also break our second live demo without having to launch the second scheduled attack against the protocol itself :). For this reason, we have uploaded a video which demonstrates how to stop permanently multicast traffic from being forwarded by abusing MLD, here [attention: 100 MB file].
For more details (as for instance, the attacks against the protocol step-by-step) and some more findings, please see here. Last but not least we will present an updated version of the talk at the Troopers IPv6 Security Summit 2015.
So, should MLD be reconsidered? In my humble opinion, yes!
Hey Antonios and Enno,
Great write up and thanks for sharing the preso. I just took a quick look but I didn’t see exactly how you attacked routers/switches/Hosts. Specifically for attacking routers/switches and multicast – if you show exactly how you attack, I suspect there are ways to mitigate/block many or maybe even all of these attacks? It would be an interesting exercise to see if all the attacks can in fact be mitigated. Is this what you’re planning to do at Troopers? Let me know if you are interested in any assistance/vetting.
Also, my impression is that Cisco (this is just a hunch) will/is going to allow link-local groups (multicast traffic) to bypass MLD snooping by default with a knob to enable it if you want. I think NX-OS does this with IGMP. I think this is the way to go. At first I thought MLD snooping was a nice defense against some link-local attacks. However, as you clearly show, it just doesn’t scale. If you only use MLD Snooping for non-link-local groups though, I think it should be sufficient. I know on the v4 side there are lots of controls and limiters. It would be interesting to see if there are corresponding controls on the v6 side and hence my interest in looking if the v6 attacks can be mitigated.
Keep up the great work,
thank you for your very kind comments. Step-by-step procedures to stop multicast traffic by abusing MLD are described at slides 48, 49, 51, 52 and 55. If you have any furher questions, or you need any clarification, please let us know. We would be very happy to discuss it with you.