Subject: Re: dictionary attack on nameservers

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Aug 2004 14:33:37 -0700

Why not persuade people to 'get with the program' by meeting their perfectly
reasonable security goals?

Seems a better plan to me than trying to persuade them that you understand
their security requirements batter than they do.

 -----Original Message-----
From: 	Paul Vixie [mailto:[email-masked]]
Sent:	Tue Aug 03 12:59:38 2004
To:	namedroppers
Subject:	Re: dictionary attack on nameservers 

> What is more likely to fracture the namespace is if half the world
> deploys DNSSEC and half doesn't, which is what we are all (?) trying
> to avoid, I thought.

the longer this debate goes on, the happier i am that something like DLV
exists.  domainholders want dns security and don't (for the most part)
care about enumeration since they can use split-dns or just live safe
with the knowledge that their zones are too numerous and too sparse to
be worth a dictionary attack.  registry operators are very concerned
about enumeration, for operational or business (or both) reasons.  without
something like DLV, i'm convinced that the part of the world who would
have the ability to deploy DNSSEC is far smaller than half of it.  with
something like DLV, i'm convinced that the half of the world who implements
DNSSEC will incentivise the other half to get with the programme, "somehow."

--
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/>

--
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: Ben Laurie <[email-masked]>
Date: Thu, 05 Aug 2004 18:22:41 +0100

Peter Koch wrote:
> Miek Gieben <[email-masked]> wrote:
> 
> 
>>The main point of my post is that I can enumerate (for +/- 90%) a zone
>>in 24 hours, even if AXFR is blocked. 
> 
> 
> thanks for this effort, hard data is a Good Thing.

It is, but this is not hard data.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 11:58:14 -0700

> the hard part of proving this is that to do a proper job, one 
> would have to have the same kind of monetary incentive that a 
> true data miner would have.  but that monetary incentive 
> invariably comes with a disincentive to publish one's results
> and methods.

That is precisely the point. In the real world raising the cost of 
an attack to the point where it is greater than the expected rewards
is a very effective way of discouraging organized crime.

The fact that such information is not available today without cost
is a demonstration that the existing controls do have an effect.

You can design a secure protocol here or you can insist on sticking
to a misunderstanding of a 20 year old dogma. The point about the
security through obscurity argument was that it applied to discussions
of *architecture* not specific configurations. At the time there
were people who did not want any discussion of computer security at 
all at any level. Today we discuss architecture, but nobody openly
discusses configuration data and applying the security through
obscurity argument at that level is invalid.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 16:59:26 -0700

y concede, and we seem to be slowly showing.
> 
> actually, i don't find "triviality" to be a relevant standard 
> for this.
> what i want to know (or even prove or disprove) is whether 
> it's already
> being commonly done and whether putting more effort into 
> avoiding "zone
> walking" is an instance of the general principle called 
> "closing the barn
> door after the animals have already escaped."

We know that it is not currently happening at the level of the 
delegated domains. 

Deploying DNSSEC in the TLDs is kinda pointless unless the 
security concious delegated domains want to join in.

I don't intend to waste my time as an advocate for a system
that provides an intangible long term benefit at the cost
of an obvious and solvable near term benefit. And I don't
think that many other security specialists will either.

One of the reasons I am arguing about the topic here is that
it is obvious to me as a security specialist that this issue
is going to be solved sooner or later. Ergo it is obvious that
the spec will not be finished until this happens.

As Karl Marx put it:

The philosophers have only interpreted the world in various ways; 
the point, however, is to change it.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 18:02:39 -0700

> More to the point, what benefit do these people have in 
> getting all these
> names/addresses? What do they do with it?

In the case of a business operating split DNS as example.com they discover
the names and addresses of all the machines that are externally accessible.

If the gang is a DDoS extortion racket they can then DDoS the systems that
perform the business processes of example.com until such time as the company
pays over $50,000 by making money transfers to a bank in Eastern Europe
where the cash is then picked up by co-conspirators.

If I am doing Web Services and a machine is DDoS attacked my first recourse
is likely to be to change the IP address and DNS name of the service and
update the Web Service description in the UDDI directory which is an access
controlled resource.

If the DDoS returns I am then going to look at the UDDI directory logs to
see which parties retreived the new location. At that point I respond to
attacks by introducing multiple names on different IP addresses and keep
changing arround until the sources of the attack have been isolated.

I can defend against this attack in the real world, but not if the DNS zone
example.com is trivially enumerable.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 07:03:35 -0700

> 3. Attackers, being script kiddy's and others. These gals and 
> guys usually probe ranges of IP-adresses, not domainnames.

Please, you are five years out of date here. The Juvenile delinquents
of the 1990s have grown up and some of them are supporting their
family through crime.

The problem today is NOT script kiddies. The problem is comming from
organized crime gangs in Eastern Europe, Russia, West Africa and
Boca Raton Florida.

These people have long criminal histories and they have brought age
old frauds to the net. DDoS extortion is simply an updated form of
protection racket. Advance fee fraud dates back to the crusades.

	Phill

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 17 Aug 2004 16:45:35 +0200

[Quoting "Hallam-Baker, Phillip", on Aug 17, 16:15, in "RE: dictionary attac ..."]
> protection racket. Advance fee fraud dates back to the crusades.

Phillip,

I'm affraid that I don't understand what link you see between
"organized crime gangs in Eastern Europe, Russia, West Africa and
Boca Raton Florida" and the difference between 20, 50, 80, 90, 99,
or 100% enumerability of zonefiles (which is what the discussion
is or was about, I thought).

If new requirements for DNS and/or DNSSEC are needed to cope with
these new forms of criminality, please specify those requirements.
Only if those requirements are expected to be effective and
cost-worthy, we should start planning on further definition,
implementation and deployment. Sofar, it looks like very costly
ghost-hunting.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 13:19:31 -0700

> > Every argument raised on this list was raised fifteen years ago when
> > I was arguing the need for shaddow passwords in UNIX.
> 
> Really?  People said passwords are supposed to be public?  People said
> there were other easy ways of figuring out most users' passwords? 
> Fascinating.

People demanded that the encrypted password file be world readable.

The creation of shadow password files was very contentious at the time.
Turning on shaddow passwords was claimed as a security vulnerability.

Proposals that UNIX introduce a means of using ACLs to control acess
to the password file was met by exactly the same response that has
appeared on this list. Namely derision, claims that it is security
through obscurity, claims that the architecture of UNIX is inviolate,
claims that the additional complexity is unwarranted, claims that 
the solution is for users to get a clue, etc. etc.

Of course the shaddow password schemes on many unix clusters are
still useless because they don't have a real distributed auth scheme
and they simply ship arround the one way encrypted password file
so the systems are compromise one, compromise all. But at least it
is now possible to secure a UNIX cluster if you know what you are 
doing without having to rewrite the O/S or patch it.

	Phill

---

From: Florian Weimer <[email-masked]>
Date: Wed, 18 Aug 2004 16:39:33 +0200

* Roy Badami:

>>>>>> "Florian" == Florian Weimer <[email-masked]> writes:
>
>     Florian> If the data were privacy-sensitive, it couldn't be shared
>     Florian> at all without explicit consent from the domain name
>     Florian> owner (at least according to most EU law). 
>
> That's an oversimplistic view of data protection legislation.  One of
> the principles in the UK implementation is that personal data can only
> be used for the purposes for which it was collected.

Yes, of course.  This means that if NS RRs (or other TLD zone
contents) were personal data, .COM/.NET registrars would have to
disclose what happens with this data (that is, VeriSign republishes it
in bulk, without any privacy safeguards).  However, hardly any
registrar does this right now.

For TLD owners, there might be other contractual obligations not to
publish the zone contents in bulk.  In this case, these obligations
should be named.  I've got a huch that privacy is not the real issue.
And if it's not privacy but simply the business interest of a few
(certainly not all) TLD operators, it might make sense to refrain from
adding baroque features to DNSSEC just to please them.

In the meantime, the discussion whether domain names are comparable to
phone numbers and deserve equal protection has resurfaced in Germany.
If something goes wrong, domain names might be considered personal
data rather soonish. 8-(

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Aug 2004 09:50:38 -0700

> And .ps and .il have completely segregated backbone infrastructure, so
> that you can safely tell an attack of a .ps site from an attack on an
> .il site?

Actually no, the palestinian ISPs are all controlled by Israel.

But the point is that companies with .il or .ps domains do not have to
use domestic ISPs. Most of the Palestinian sites are in .com and are
hosted outside the country but there are not very many of them.

> In this case, wouldn't it be easier to go for the infrastructure
> itself, and not for specific sites?  Or are we talking about attacks
> on the application layer?

It is application layer attacks. You take a .il site, crack it, then
bring up some propaganda pictures on the hacked site. 

> (I'm a bit surprised because it's hard to imagine for me that the
> infrastructure is so clearly separated.  Unfortunately, I haven't got
> enough data on .ps and .il to provide some evidence with respect to
> shared hosting.)

It isn't really, but the hackers don't much care about collateral 
damage.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 30 Aug 2004 10:23:57 -0700

> Roy Arends writes:
> > Quickly scan a class B for resolvers, take the bulk (say 2000), and
> > ask them for stuff under gotcha.example.com.
> 
> Why does the IETF condone promiscuous DNS caching?
> 
> I'm reminded of the situation in 1996, when qmail (version 
> 0.91) became
> one of the first MTAs to prohibit relaying by default. People at the
> time didn't realize that relaying was going to be massively abused.

People seem to get very wound up about security, demanding all or
nothing, then being surprised when they end up with nothing.

How much of the protection against DNS spoofing would be provided
by a simple transport layer challenge-response mechanism?

The client sends an authenticatable nonce en-clair along with
the request.

The server returns both the nonce and an HMAC signature of the 
response.

If you can work out a way to know with certainty whether a 
DNS server supports the protocol you have a very robust 
authentication scheme that can only be defeated by a man
in the middle attack.

		Phill