Next week, at DeepSec, we’re going to give a talk about Multicast Listener Discovery (MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively) and while MLD is technically implemented by ICMPv6 exchanges, these specifications describe a whole set of rules and communication formats, hence we can safely talk about “the MLD protocol”.
Now, you might ask: how does one tackle the task of examining the security “of a protocol”?
In the past we’ve done this, amongst others, by:
- looking for implementation flaws, mostly by fuzzing (like here or here, see also this & that).
- analyzing the cryptographic properties and trying to break them (like in this one, more details here).
- evaluating the protocol(s) with regard to design flaws with subsequent exploitation of those, or just (“inherent”) properties of a protocol which can be (ab-) used in certain ways or scenarios (for example here).
Given MLD has no cryptographic properties and, on the other hand, is a quite complex beast ;-), during the research on MLD we mostly focused on the first (fuzzing) and the third approach.
When reflecting on protocol properties and potential design flaws, there’s a set of guiding questions we consider. Some of these are the following:
a) what is the scope where interaction of $PROTOCOL usually takes place?
Or, the other way round, “from where” can one attack a component “speaking
$PROTOCOL” (read: which has $PROTOCOL enabled)?
Furthermore: often, in the course of a multi-phase multicast/broadcast based
communication, some unicast is happening. This leads then to the question:
“under which circumstances can unicast communication” be used?
For the simple reason that unicast packets can usually be sent from “remote”
(whereas, e.g., forwarding of packets with multicast source addresses is often
[to be] denied by routers).
Processing unicast packets as part of a broad-/multicast based exchange can
either be an implementation flaw (if that is explicitly covered/forbidden in the
specs) or a “corner case not sufficiently thought through by the developers”
(e.g. back in 2005 or so, the HSRP implementation on some Cisco images accepted
[unicast] HSRP packets coming in “from remote”).
Another thing in this context: is there any checks on a packet’s origin’s scope (like “does it still carry 255 as TTL/hop-limit?”) and, if so, is this implemented correctly?
b) What are the authentication properties/capabilities?
There is huge number of protocols that don’t have any authentication built in at
all (see for example
this old talk
from Day-Con), MLD not being an exception
(potentially due to the
broken trust model of IPv6).
Still,
even if they have, additional questions include: Are those enabled/required by
default? How are they used in real-life?
c) Does the protocol influence packet forwarding decisions, either directly (as
in the case of routing protocols) or indirectly (e.g. DNS)?
If so, successful attacks can lead to traffic redirection and hence breaches of
confidentiality/integrity.
d) Is there any kind of election process (e.g. of a “master” functionality)
performed? Nice candidates are STP or HSRP.
What are the parameters needed for this election?
Can they be set “freely”? For example, in VRRP it’s not foreseen that any device
ever acts with priority of 255 (see slide #31f. of
this talk :-),
but – of course – an attacker could craft it.
This is particularly interesting if there is no/weak authentication properties.
e) What is the amount of state (“ideally” on the control plane) network devices
keep, related to $PROTOCOL?
The higher the amount of state is the higher, usually, the susceptibility to
flooding attacks.
Once flooding happens what’s the (foreseen|observed) behavior of devices then?
e.g. go to “fail-open” or “fail-closed” mode?
f) What’s the ratio of packets sent by an originator and the potential response
traffic, either from one system (think SNMP bulk requests/walks) or – “even
better” –many systems responding?
Can we influence this (e.g. by adding additional parameters to query type of
packets)?
This one plays a significant role for DoS attacks.
Again, here the aspect of authentication and/or scope-/parameter checking might play a role.
Some years ago, when I gave network security workshops (like the predecessor of this one) I used to put together a little table with the participants to gain a better understanding of typical protocols to be found in LANs and to think about protection approaches. At the time – the timestamp of the file is from 2009 😉 – this table looked like this:
For MLD we went through all these questions and found interesting, at times surprising results, to be discussed in our talk ;-).
One more thing: to perform the attacks Antonios coded MLD functionality into his
IPv6 attack suite Chiron, and Jayson
developed a MLD module for dizzy. Both will be released at DeepSec.
If you’re not familiar with Chiron’s capabilities, you might consider attending
our workshop on IPv6 security as
well. It will be used & covered in detail there.
Stay tuned for more on MLD security and/or see you in Vienna!
Enno