This is a guest post from Antonios Atlasis.
On Thursday the 20^(th) 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!
Antonios