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

Alfred Hönes <ah@TR-Sys.de> Mon, 20 September 2010 14:03 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD373A6A91; Mon, 20 Sep 2010 07:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.024
X-Spam-Level:
X-Spam-Status: No, score=-96.024 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlUyX2N7NeTX; Mon, 20 Sep 2010 07:03:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A15FF3A6A8A; Mon, 20 Sep 2010 07:03:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Oxgsp-000CbY-K1 for namedroppers-data0@psg.com; Mon, 20 Sep 2010 13:58:15 +0000
Received: from gateway.tr-sys.de ([213.178.172.147] helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1Oxgsi-000CVb-MF for namedroppers@ops.ietf.org; Mon, 20 Sep 2010 13:58:09 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA193700934; Mon, 20 Sep 2010 15:55:34 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA23347; Mon, 20 Sep 2010 15:55:32 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201009201355.PAA23347@TR-Sys.de>
Subject: Re: [dnsext] A security concern regarding IPv6 support in name servers
To: nweaver@icsi.berkeley.edu
Date: Mon, 20 Sep 2010 15:55:32 +0200 (MESZ)
Cc: namedroppers@ops.ietf.org
In-Reply-To: <33355710-F8B0-4067-93BF-EC3663BE39CD@icsi.berkeley.edu> from Nicholas Weaver at Sep "20, " 2010 "06:05:03" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

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:
>
>> 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.
>
> 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.