Subject: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks

From: Toerless Eckert <[email-masked]>
Date: Sun, 25 Oct 2020 20:24:56 +0100

Ben Kaduk (SEC AD) was wondering about the appropriateness of a hardening suggestion
in draft-ietf-anima-autonomic-control-plane-29. Let me translate this into
mDNS, even though its about GRASP, but IMHO for the purpose of this issue
its equivalent:

Node wants to discover on a LAN a particular service and unfortunately, attackers
on the LAN want to spam it.  For example by sending out a significant number
of false mDNS messages claiming the service is available on a variety of 
of ports (lets keep attacks against other serive parts like the I address
out of this). And in effect, the node will attempt a lot of service instantiations
to bogus ports.

Now, in one case, the service may have an IANA registered well-known TCP or UDP
port number. So the hardening recommendation in our draft text is that if a lot
of answers are received AND the node knows that there is a well-known port, then
it should prioritize trying the service over that well known port.

Any reason why this would not be a good obvious heuristic ?
Has this been considered for mDNS alreay anywhere (rfc ?).

Of course, if there is no well known port, this does not help. And if
the non-attacker can only offer a service with a well-known port number only
on a non-well-known port number, than it actually hurts, but i think those
are unavoidable limitations. And it easily spells out that one of the
key benefits of getting a well-known port number for something is to
be able to avoid having to guess in the face of such attacks, when discovery
of port number can not be secured.

Aka: In our case we have one potential upcoming service over DTLS, and
this text could help decide later on if we wanted to apply for a
well-known port number for this service if we get operational experience
that that could help in conjunction with this hardening recommendation.

Cheers
    Toerless

P.S.: for original text in subject draft look for "Attackers on a subnet may be able to inject malicious"

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Oct 2020 15:41:26 -0400

That would be a very bad heuristic. The whole point of SRV records is to eliminate the dependency on reserve ports. 

Really this is a non problem. We are not seeing this on home networks at present, because it’s just not an interesting attack. But supposing that we wanted to do something about it, the way to do so would be twofold. 

First, use protocols that allow for establishment of trust so that an on link spammer’s offered service can’t mimic a trusted service. E.g., use self signed certs and TOFU to prevent spoofing. 

Second, switch away from Multicast to DNSSD over DNS, and establish trust that way. If services register using DNSSD Service Registration Protocol, FCFS naming prevents spoofing of trusted services. 

Of course there always has to be a trust establishment process, like BRSKI. 

I’m sure that something similar can be done with anima. 

> On Oct 25, 2020, at 15:25, Toerless Eckert <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 17:59:15 +0100

Thanks, Ted.

I agree with your overall assesment, but the question was what
an implementation should do in the face of a particular pre-existing
condition: Aka: With mDNS or GRASP as they both stand today
(me of course right now primarily interest in GRASP< but if
 implementation/operational guidance for mDNS existed, i could simply
 point to that).

The networks where i am worried are not home networks,
but something like an office park network, where supposedly each
tenant (company) should have gotten their disjoint L2 domains, ... and then
they didn't. And one of the tenants has a "funny" network engineer/hacker.

So, eliminate for your assessment the option of better
protocols. Now, why would this heuristic then still be
"very bad" ? To me it just eliminates the benefits of
dynamic port signaling when there is an attack. And has no
impact under no attack.

Cheers
    Toerless

On Sun, Oct 25, 2020 at 03:41:26PM -0400, Ted Lemon wrote:
> Really this is a non problem. We are not seeing this on home networks at present, because it???s just not an interesting attack. But supposing that we wanted to do something about it, the way to do so would be twofold. 
> 
> First, use protocols that allow for establishment of trust so that an on link spammer???s offered service can???t mimic a trusted service. E.g., use self signed certs and TOFU to prevent spoofing. 
> 
> I???m sure that something similar can be done with anima. 
> 
> > ???Ben Kaduk (SEC AD) was wondering about the appropriateness of a hardening suggestion

-- 
---
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 13:05:42 -0400

> they didn't. And one of the tenants has a "funny" network engineer/hacker.

That’s pretty clearly the thing to fix.
 
> dynamic port signaling when there is an attack. And has no

If you’re going to do that, you might as well just turn off mDNS entirely.

I don’t know whether or not this would also be true of GRASP, however.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 26 Oct 2020 13:11:33 -0400

> On Oct 26, 2020, at 1:05 PM, Ted Lemon <[email-masked]> wrote:
> 

There’s plenty of bad engineering out there, but when on a shared lan without client isolation enabled (Eg: wireless) many bad things can be done.

I think explaining that the threat domain is the layer-2 and that administrators should consider what services are available, eg: do you accept dhcp server on the network, what devices are permitted to send RA’s etc all become part of the question..

Much of this is just operational guidance in how to run a good network which prevents these types of bad behaviors and consequences from exceeding their blast radius.

- Jared

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 18:30:18 +0100

On Mon, Oct 26, 2020 at 01:05:42PM -0400, Ted Lemon wrote:
> That???s pretty clearly the thing to fix.

The whole point is to build solutions on top of underlays where there can be attacks, right ?

> If you???re going to do that, you might as well just turn off mDNS entirely.

How is this worse than NOT doing this heuristic ? 

No difference under no attack.

What heuristic would you use under attack, and why ?

> I don???t know whether or not this would also be true of GRASP, however.

So far i do not see a difference except for deployment cases (home vs. more difficult / potentially more easily attacked underlays, but then again, mDNS is widely used within universities/schools too, sone might argue that there is not even a different in deployment).

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 18:42:21 +0100

Thanks, Jared

Somehow everybody tries to escape answering the question asked by giving
their correct but orthogonal pet problem space answer. Ted correctly claims
the protocols suck security wise, and you correctly claim that there are a lot more
deployment considerations in face of risky underlays.

At this point in time i am just trying to get an RFC out the door, and Bens
security review was asking for options how to operationalize the choosen protocol
to be hardened. My answer was the heuristic.

If the anwer of the experts is "do not harden implementations of existing protocols",
but only improve protocols or eliminate security risks from underlays, i think
that is not a good strategy to show to implementors trying to understand how
to best harden existing protocols, but i will happily take that guidance
and remove the text about the suggested heuristics.

Cheers
   Toerless

On Mon, Oct 26, 2020 at 01:11:33PM -0400, Jared Mauch wrote:
> There???s plenty of bad engineering out there, but when on a shared lan without client isolation enabled (Eg: wireless) many bad things can be done.
> 
> I think explaining that the threat domain is the layer-2 and that administrators should consider what services are available, eg: do you accept dhcp server on the network, what devices are permitted to send RA???s etc all become part of the question..
> 

-- 
---
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 13:54:09 -0400

> How is this worse than NOT doing this heuristic ? 

It’s likely exactly the same. My expectation would be that the port in the SRV record is literally never the port number in the services table, with a few exceptions like ssh, which has a trust establishment framework and can’t be easily attacked using your proposed attack.

The sense in which it might be worse, though, is that it might fail sometimes, but not always. This makes it harder to figure out why it’s not working. You might not even realize that the problem is mDNS.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 26 Oct 2020 16:05:38 -0400

> and remove the text about the suggested heuristics.

	I think we often forget several things about the security aspects
of devices, like physical access == root (for example), on-link or on-network
attackers will always have an advantage available to them.

	Things like mDNS are only as secure as their local link, and if an attacker
is on-link there are risks that can be controlled for and those that can't.

	We have had problems elsewhere as md5/tcp-md5 provide engouh mutual peer
authentication to be of value, but can be broken with a persistent on-link or
on-path attacker.

	I was also just providing examples of other protocols (dhcp, ra) that
share the same on-link risks.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 16:09:41 -0400

>> and remove the text about the suggested heuristics.

The point of my answer was not “don’t do anything to harden it,” but rather “don’t do _that_.”  :)

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 21:14:48 +0100

On Mon, Oct 26, 2020 at 04:09:41PM -0400, Ted Lemon wrote:
> The point of my answer was not ???don???t do anything to harden it,??? but rather ???don???t do _that_.???  :)

And the question from the AD was what could be done. So, do you have any
implemention suggestion ? Are there any sugestions for mDNS ?

(and i do not mean "harden the underlying L2 network" or "create a better protocol").

Btw: I do agree that for most use of mDNS as it is relying on dynamic ports,
my suggestion would create an undesired trend of allocating static port numbers.
This is also true for GRASP in general, but for the specific use-cases
in mind in my text, which are really inside-network infra protocols, the argument could be
made that static port allocation was indeed well feasible (as we're talking about a
very small number here) . But we had not done it because we hadn't vetted the benefits
of doing such a port allocation.

Cheers
    Toerless

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 16:39:10 -0400

> implemention suggestion ? Are there any sugestions for mDNS ?

There are no simple mitigations. If there were, they would already be in the protocol.

> of doing such a port allocation.

If it’s a multicast discovery protocol with no authentication, then constraining the set of allowed ports just means that the node that’s attacking you has to be able to listen on that port, which it likely can. So I think this reduces function without increasing hardening.

What actually hardens mDNS is that it’s a link-local protocol. It doesn’t work across links. This limits the attack surface. But there’s no way to eliminate the attack surface.  If I were in Ben’s shoes, I’d be asking you to change the protocol to support authentication and ToFU as a hardening strategy, with some better trust establishment mechanism as future work based on the existing presence of crypto signatures. But the current consensus of the IETF is apparently that ADs aren’t allowed to insist on things like that. :(

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 21:52:10 +0100

> There are no simple mitigations. If there were, they would already be in the protocol.

And with protocol you also include local state machineries such as the
heuristic i described ? (sorry, just wanting to make sure).

> If it???s a multicast discovery protocol with no authentication, then constraining the set of allowed ports just means that the node that???s attacking you has to be able to listen on that port, which it likely can. So I think this reduces function without increasing hardening.

Elimination of the port number as an announced service element (and instead assuming
 there is a well-known port) eliminates the amplified attack of sending such announcements
with a sweep of port numbers and therefore condemning the consuming client to
try out all those port numbers.

> What actually hardens mDNS is that it???s a link-local protocol.
> It doesn???t work across links.

I am not aware that the solutions to extend mDNS across multiple hops
would be any more hardened necessarily. But water under the bridge.

> This limits the attack surface.
> But there???s no way to eliminate the attack surface.
> If I were in Ben???s shoes, I???d be asking you to change the protocol
> to support authentication and ToFU as a hardening strategy,
> with some better trust establishment mechanism as future work based
> on the existing presence of crypto signatures.
> But the current consensus of the IETF is apparently that ADs aren???t allowed to insist on things like that. :(

Well, it would singling out new work with a humunguously higher bar to jump
over than widely used protocols even including similar DoS attack in
DAAD if i am not mistaken (given how mDNS isn't all that prevalent).
Or just look at how convoluted the work was to attempt making process
with neighbor discovery in routing protocols.

Actually for our specific use-case i would like to propose an authenticated
method, alas there is no pre-established knowledge of the cert of the
neighbor, so it might have to include the whole bloody cert in a packet to authenticte
the packet, and that might be problematic size-wise. Maybe payload-layer
segmented multicasting *sigh*. Discussion for another time.

-- 
---
[email-masked]

---

From: Jared Mauch <[email-masked]>
Date: Mon, 26 Oct 2020 17:17:30 -0400

On Mon, Oct 26, 2020 at 04:39:10PM -0400, Ted Lemon wrote:
> What actually hardens mDNS is that it’s a link-local protocol. 
> It doesn’t work across links. This limits the attack surface. 

Exactly.

> But there’s no way to eliminate the attack surface.  If I were in Ben’s shoes, 
> I’d be asking you to change the protocol to support authentication and 
> ToFU as a hardening strategy, with some better trust establishment mechanism 
> as future work based on the existing presence of crypto signatures. But 
> the current consensus of the IETF is apparently that ADs aren’t allowed to 
> insist on things like that. :(

We must also consider that mDNS is meant to provide that on-link communication
for devices that are perhaps not professionally managed, such as my
home where I may want to talk to raspberrypi.local or my printer
or other on-link device without placing it in some enterprise or other
lookup system.  This helps prevent remote attacks and discoverability of
my devices and provides security this way.

- Jared