Subject: [dnsext] A security concern regarding IPv6 support in name servers

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Sep 2010 14:28:55 +0200 (MESZ)

I have been pointed to a paper by H. D. Moore published in 2008,
"Exploiting Tomorrow's Internet Today - Penetration Testing with IPv6",
available at <http://uninformed.org/?v=10&a=3&t=pdf>.

On page 3, this paper points out that Bind running on an IPv6-enabled
system, unless its serving socket is bound to a specific IPv6 (unicast,
interface-assigned) address of the system, also listens to multicast
traffic (the memo apparently confuses the terms "broadcast" and
"multicast") and will also respond to DNS queries received over IPv6
multicast (e.g., to FF01::1).  This could be leveraged for discovering
nodes and for various amplification / DoS attacks.

So there's the question:  Is this considered a feature or a bug?
Is this still current behavior in the latest versions of Bind?
Do other DNS server implementations expose the same behavior?

Note that IP packets MUST NOT be sent with a source address that is
a multicast address (or the limited broadcast address in the case
of IPv4); therefore, a resolver that actually sent such multicast
query would likely recieve a response to such query that uses a
unicast address of the system running the DNS server as its source
address, and such response would be rejected _if_ the resolver
follows Section 9.1 of RFC 5452.  And based on the same rules, such
response would be rejected as well if the resolver did not send the
query (the source addr of the query had been spoofed by an attacker),
and the response hence does not match an outstanding query.

Although the RFC 5452 checks reduce the possible resulting damage,
in the standard DNS protocol (using server port 53), preferably
such responses should not be sent at all in the first place.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 20 Sep 2010 06:05:03 -0700

> nodes and for various amplification / DoS attacks.

Except that if you are on the multicast domain of the victim, the victim is already screwed for reconnisance, because the other systems (eg, Macs, windows, etc) use multicast link-local and network-local IPv6 a lot for autoconfiguration.  

Just listening, let alone generating, traffic to the link local multicast will pretty much tell you everything in the network you might want to exploit.

ANd in fact the victim is just screwed because you can use ICMP6 router advertisements etc to direct the victim's internet traffic wherever you want to go.

Basically, if an attacker is within your IPv6 subnet (so link-local/site-local multicast works) you are totally lost.

And thus responding to requests on multicast is probably a Good Thing, as it enables inside-the-perimeter autoconfiguration and fallback, multicast-dns support, etc.

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Sep 2010 15:55:32 +0200 (MESZ)

Nicholas,
I do not share all of your explanations, in particular with RFC 5452
in mind.

> On Sep 20, 2010, at 5:28 AM, Alfred Hönes wrote:
>
> Except that if you are on the multicast domain of the victim, the
> victim is already screwed for reconnisance, because the other systems
> (eg, Macs, windows, etc) use multicast link-local and network-local
> IPv6 a lot for autoconfiguration.
>
> Just listening, let alone generating, traffic to the link local
> multicast will pretty much tell you everything in the network you
> might want to exploit.

All agreed so far.

> And in fact the victim is just screwed because you can use ICMP6
> router advertisements etc to direct the victim's internet traffic
> wherever you want to go.

Right, but thereby services running on nodes cannot be identified.

> Basically, if an attacker is within your IPv6 subnet (so
> link-local/site-local multicast works) you are totally lost.

The primary question is whether you (as a DNS server) can/should
avoid actively contributing to the success of an attacker.

> And thus responding to requests on multicast is probably a Good Thing,
> as it enables inside-the-perimeter autoconfiguration and fallback,
> multicast-dns support, etc.

The question was *not* posed wrt mDNS / LLMNR; it specifically was
targeted at 'classical' (== standard) DNS service offered at port 53.

My reasoning is that a resolver following RFC 5452 will drop any
response to a multicast DNS query because that response cannot be sent
with the destination multicast address of the query as its source
address (the IP layer of the server will hopefully prohibit this)
and hence the src<->dst {addr,port} matching rules of RFC 5452
will declare the response as invalid.

So why would a DNS server want to send a response packet to a
multicast query, if any conforming recipient (resolver) will
drop the packet anyway?  And if the src addr of the query was
spoofed, the DNS server would contribute actively to an attack.

Kind regards,
  Alfred.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Sep 2010 10:27:59 -0400

>avoid actively contributing to the success of an attacker.

Whether you are driving (on the autobahn) a truckload of volatile 
explosive material or a van full of 8 year olds, you should do your 
best to avoid an accident.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 20 Sep 2010 07:50:22 -0700

On Sep 20, 2010, at 7:27 AM, Edward Lewis wrote:

> Whether you are driving (on the autobahn) a truckload of volatile explosive material or a van full of 8 year olds, you should do your best to avoid an accident.

When you are dealing with a house with no front door and no real ability to build a front door, do you worry about the integrity of the bathroom skylight?