Subject: Fingerprinting DNS implementations.

From: Roy Arends <[email-masked]>
Date: Tue, 9 Dec 2003 22:49:25 +0100 (CET)

Hi,

Jakob and I spent the past few weeks hacking up a DNS implementation
fingerprint tool (where implementation == anything responding to a query).
This mail introduces the methodology of fingerprinting DNS
implementations.

A nameserver basically responds to a query.  Inter-operability is an
obvious requirement here, the standard protocol behaviour of different DNS
implementations is expected to be the same.

Protocol behaviour of a DNS implementation is widely documented in the
case of a 'common' query.  The DNS protocol is over 20 years old and since
its inception, there have been over 40 independant DNS implementations,
while some implementations have over 20 versions.

The methodology used to identify individual nameserver implementations is
based on "borderline" protocol behaviour.  The DNS protocol offers a
multitude of message bits, response types, opcodes, classes, query types
and label types in a fashion that makes some mutually exclusive while some
are not used in a query messages at all.  Not every implementation offers
the full set of features the DNS protocol set currently has. Some
implementations offer features outside the protocol set, and there are
implementations that do not comform to standards.

Also, new features added to - or bugs removed allow for differentiations
between versions of an implementation.

Methodology

We use a serie of "borderline" query-response messages to identify
implementations.  A serie of query-response messages form a sequence.
We call the interpretation of these series to form a conclusion "DNS
sequencing".

As mentioned, responses to a "borderline" query is used in this method.
To be somewhat efficient, a tree can be constructed which consists of
queries (nodes) and responses (branches), where the leave nodes identify
the implementation.

Every path, from the root node (initial query) to a leave node (final
query) is essentially a "strain".  The strains are used to distinguish
between, and as said, ultimatly identify implementations.

Parallel to this technique it is possible to identify some brands and
their versions by doing a specific query asking for the servers' version.
This technique does not satisfy our requirement since this has not been
implemented in all brands of nameservers (it is not part of any standard),
operators may have obscured the information and there are implementations
that try to resolve the query, essentially asking root-servers from a
different class for their version.

Implementation.

Our current software is written as a proof-of-concept. In field tests,
false positives were encountered when trying to identify a set of servers
residing behind a load-balancing apparatus where the servers itself are of
different implementations, or when a specific implementation behaves like
a forwarder.

We are actively looking for implementations not yet identified by this
tool to complement the set of strains.

The current set of strains identify the following implementations
and their versions:

ATLAS
BIND 4
            BIND 4.8 -- 4.8.3
            BIND 4.9.3 -- 4.9.11
BIND 8
            BIND 8.1 -- 8.2.1T4B
            BIND 8.2.1
            BIND 8.2.2P3 -- 8.4.1
            BIND 8.4.1P1
BIND 9
            BIND 9.0.0b5 -- 9.0.1
            BIND 9.1.0 -- 9.1.3
            BIND 9.2.0a1 -- 9.2.0rc3
            BIND 9.2.0rc4 -- 9.2.2P3
            BIND 9.2.3rc1 -- 9.4.0a0
eNom DNS
Incognito DNS Commander
MARADNS
Microsoft Windows
            Server 2003
	    Server 2000
            Server NT4
MyDNS
Nominum ANS
Nominum CNS
NonSequitur DNS
NSD
Oak DNS
Pliant DNS Server
Posadis
PowerDNS
	    2.8 -- 2.9.3
            2.9.4 -- 2.9.11
QuickDNS
Simple DNS plus
TinyDNS
UltraDNS

We are actively looking for volunteers who allow us to identify their
running code in some form or configuration of some version of:

chives
custom-dns
dents
dnrd
dnsmasq
gnudip-www
ibmdns
jeeves
lbdns
lbnamed
ldapdns
MacDNS
Microsoft Windows Server NT3.51
pdnsd
Stanford::DNSserver
yaku-ns

and/or

All other unidentified, unmentioned original code.

Thanks,

Roy Arends
Jakob Schlyter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Dean Anderson <[email-masked]>
Date: Tue, 9 Dec 2003 17:37:44 -0500 (EST)

I'm wondering why you are doing this.  This sort of tool could be abused 
by crackers.

I am particularly where is sounds like your are looking for fingerprints
for vendors that have obscured their responses in order to prevent
fingerprinting.

DNS is a critical piece of infrastructure, and fingerprints allow the 
cracker to use the right attack the first time, without revealing their 
attack.

		--Dean

---

From: Jim Reid <[email-masked]>
Date: Tue, 09 Dec 2003 23:40:13 +0000

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> I'm wondering why you are doing this.  This sort of tool
    Dean> could be abused by crackers.

So could many other tools. Like compilers. Do you want to ban them too?

    Dean> I am particularly where is sounds like your are looking for
    Dean> fingerprints for vendors that have obscured their responses
    Dean> in order to prevent fingerprinting.

Well perhaps those vendors would then spend time fixing security bugs
in their code instead of investing in futile efforts to conceal them?

    Dean> DNS is a critical piece of infrastructure, and fingerprints
    Dean> allow the cracker to use the right attack the first time,
    Dean> without revealing their attack.

This presumes the crackers and script kiddies have that sort of
finesse. If they've got a bunch of attacks to penetrate name servers,
they'll more than likely try them all and go with the ones that
succeed against their victims. And anyway, if an attack succeeds, it's
too late. The damage has already been done. How the choice of attack
was made -- if there was a selection! -- is irrelevant.

---

From: Chris Thompson <[email-masked]>
Date: Tue, 9 Dec 2003 23:55:30 +0000 (GMT)

Dean Anderson <[email-masked]> writes
 
> I'm wondering why you are doing this. 

I'm not. I'm wondering why he thinks this is a DNS protocols issue
rather than a DNS operations one.

Chris Thompson
Email: [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Tue, 9 Dec 2003 20:08:05 -0500 (EST)

> So could many other tools. Like compilers. Do you want to ban them too?

Compilers are indispensable. Fingerprinting is not (I think) 
indispensable.

> in their code instead of investing in futile efforts to conceal them?

Much easier said than done. Wait. Clancy! Fire the security bug 
developers.

> succeed against their victims. 

Well, now they can have that finesse, without even learning about DNS.

> And anyway, if an attack succeeds, it's too late. The damage has already
> been done. How the choice of attack was made -- if there was a
> selection! -- is irrelevant.

No, actually, it isn't.  The slightest irregularity can trigger discovery.  
The Debian crack was discovered because of an unexpected kernel Oops. If
they crackers had used better fingerprinting, they would have gotten in
undetected, and much more damage would have been done.  As it was, they
got in, but because of their lack of accurate fingerprinting, they were
detected (after the fact) but before they could cause great damage.

I guess we can't really prevent crackers from getting fingerprinting, if
they want to, but it seems smart people are making it easier than it has
to be.

		--Dean

---

From: Roy Arends <[email-masked]>
Date: Wed, 10 Dec 2003 15:19:45 +0100 (CET)

> I'm wondering why you are doing this.

I want to know how the DNS landscape looks like. A popularity contest.
Especially if the wg decides to clarify parts of the standards, or
standardise additions, I'd like to know the impact on the landscape,
therefor I need to know what it looks like.

Oh, and for fun as well.

> This sort of tool could be abused by crackers.

The tool does not discriminate on intend or mindset.

> for vendors that have obscured their responses in order to prevent

The tool does not discriminate in that area neither. Both implementations
that scream their version, including authors, and implementations
that do not can be identified.

Vendors do not obscure responses. How do you obscure responses ? Create
but not send ? Response-Sensorship ?

Instead of 'fingerprinting', would you like me to call it 'protocol
conformity, indexed by implementation' ?

Roy

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Dec 2003 13:53:38 -0500 (EST)

> but not send ? Response-Sensorship ?

Nmap fingerprints OS's by TCP signatures, using much the same methods as
you described, in principle anyway.  There are tools for linux and I think
*BSD that will alter the responses so that this fingerprinting fails to
identify the true OS.

This could get into a sort of war of fingerprinting and obscuring changes,
which would seem to be destructive...

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Dec 2003 20:05:38 -0600

> which would seem to be destructive...

Or, it could turn into a war of bug fixing, which would be 
constructive, and would motivate people to move to less buggy versions 
of their name server software.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Dec 2003 23:00:21 -0500 (EST)

On Wed, 10 Dec 2003, Ted Lemon wrote:

> Or, it could turn into a war of bug fixing, which would be constructive,
> and would motivate people to move to less buggy versions of their name
> server software.

I'm Doubtful. The (linux) fingerprint changes seem (to me anyway--not an
expert on the exact changes), gratuitous changes that aren't expected to
actually break anything. This is a far cry from fixing bugs.  Its just
busy work created by the need for a response to fingerprinting.  Its also
not usaully done in the mainline, but as optional changes, basically
making it seem like there are more versions then there are.

		--Dean

---

From: "Mathias Samuelson" <[email-masked]>
Date: Thu, 11 Dec 2003 09:34:47 +0100

> and would motivate people to move to less buggy versions of their name 

Just my $0.02. It's, as you all know, surprisingly often the case that 
the network operators aren't even aware of what version of software they 
are running. I've heard some people argue that they shouldn't run 
anything else than whatever version of BIND Sun bundles with Solaris, no 
matter how many vulnerabilities there's in that software. Obscuring the 
fact that one is running such software doesn't seem to be a good 
security measure anyway.

So, for what it's worth, I agree with those who are pro what Dean and 
Jakob is doing.

All best
Mathias
-- 
    Mathias Samuelson
Phone: +46 (0)8 5058 3111
      Dimension AB

You can fetch my GnuPG key (CB6D9D85) with fingerprint
B98BB34ADAA91D4F2F47E6363EC2C8BDCB6D9D85
from (e.g.) blackhole.pca.dfn.de.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 11 Dec 2003 10:01:13 +0100

Can we please move the discussion on operational impact of this tool
elsewhere; that discussion is clearly off-topic for this list.

-- Olaf
   DNSEXT Co-Chair.

---

From: [email-masked]
Date: Thu, 11 Dec 2003 07:04:47 -0500 (EST)

On Wed, 10 Dec 2003, Dean Anderson wrote:
>
> The (linux) fingerprint changes...Its just busy work created by the need
> for a response to fingerprinting.

It's just busywork, full stop. There is no "need for a response to
fingerprinting".

--Len.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Dec 2003 14:12:45 -0500 (EST)

On Thu, 11 Dec 2003, Mathias Samuelson wrote:

> I've heard some people argue that they shouldn't run 
> matter how many vulnerabilities there's in that software. 

Sun (like most vendors)  won't provide software support if you aren't
running what they bundled.  But they do provide their own updates. You 
have to take those updates.

But I don't run Bind at all for security reasons.  

> Obscuring the fact that one is running such software doesn't seem to be
> a good security measure anyway.

Certainly, in the more mature area of OS fingerprinting, quite a lot of
people disagree.  Hiding this kind of information is the first thing
security consultants recommend.  Security by obscurity is a valid and
effective form of security.  Call a bank, and ask them what kind of alarm
system they have.  Even the manuals for Airport security systems are
restricted.  This is security by obsurity.

Everything has weaknesses. Every software has an exploit.  Thinking
otherwise is unrealistic.

		--Dean

---

From: Phil Howard <[email-masked]>
Date: Thu, 11 Dec 2003 14:03:23 -0600

On Thu, Dec 11, 2003 at 10:01:13AM +0100, Olaf M. Kolkman wrote:

| Can we please move the discussion on operational impact of this tool
| elsewhere; that discussion is clearly off-topic for this list.
| 
| 
| -- Olaf
|    DNSEXT Co-Chair.

Right.  It shouldn't be here.

Can someone suggest a software-neutral mailing list or other forum for DNS
server operational discussions?

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2003 20:32:55 -0000

I posted fingerprint data a year ago: http://cr.yp.to/surveys/dns1.html

Chris Thompson writes:
> I'm wondering why he thinks this is a DNS protocols issue

The IETF often creates interoperability problems by extending protocols
in a way that breaks existing software. Today's ``borderline'' packets
could be tomorrow's protocol extensions; it's important to document how
those packets are handled.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Jim Reid <[email-masked]>
Date: Fri, 12 Dec 2003 00:12:09 +0000

>>>>> "Phil" == Phil Howard <[email-masked]> writes:

    Phil> Can someone suggest a software-neutral mailing list or other
    Phil> forum for DNS server operational discussions?

The IETF dnsop WG's mailing list would be an obvious choice.