DNS Speculation

["Joseph Patterson" <jpatterson () terremark com>]

So, now I've taken a good hard look at what someone claims is a mirror
of a post that may or may not explain the whole DNS issue.  Based on
that obviously perfectly reliable information, all I can say is "whee".
Actually, no, that's not all I can say.

 

First off, DNS is unreliable.  Film at 11.

 

Seriously.  There are quite a few technologies in wide use whose primary
purpose is to assure that the person Alice is talking to is, in fact,
Bob.  Whether Mallory is impersonating Bob by intercepting the
connection, hijacking BGP, DNS cache poisoning, or whatever, it doesn't
matter - things like SSL will not be fooled.

 

No doubt, this is a clever attack.  The quick fix is to randomize source
ports for resolvers.  That's actually pretty effective for this attack.
The slow fix is pervasive DNSSEC, but there are serious issues there.
I'd put even odds on it happening before pervasive IPSec (which would
also fix the problem)

 

But first, let's take a look at what Mallory will need in order to
successfully attack, given the absence of port randomization, DNSSEC, or
SSL.

 

First, she's going to need to know Alice's resolver.  That's not too
hard to find out, but it is an extra step to go through.

 

Next, she's going to have to somehow get a whole bunch of queries to go
to that resolver.  If it's a private resolver, that means getting Alice
to perform a whole lot of queries.  That can be done, but the timing is
tricky.

 

After that, (well, during that) she's going to have to send somewhere on
the order of 35K spoofed DNS replies "from" Bob to Alice's resolver.
That's loud.  It will also fail miserably if there's any RPF between
Mallory and the point near Alice where Mallory's traffic and Bob's
traffic start going down the same pipe.

 

So, there's a few steps, a loud attack, and it will fail if any of the
following apply:

1.      the DNS resolver already uses source port randomization (several
do) 
2.      the DNS resolver is behind a firewall that does source port
randomization for it (I know Cisco PIX/ASA does this by default and has
for some time, probably others do as well) 
3.      There's RPF in the middle 
4.      the DNS resolver doesn't cache.  That isn't all *that* uncommon.

5.      DNSSEC is being used all the way up the chain (probably less
common than non-caching resolvers) 

 

There are probably a few other ways in which the attack fails, but these
are the ones I can think of off the top of my head.  But if the attack
succeeds, then Mallory has convinced Alice's computer that Bob's name
points to Mallory's IP.  This increases the vulnerability of a small
niche:  Those users who both look at and trust DNS while using services
that don't implement strong authentication.  Users who don't suspect
that paypal's webserver might not be at http://0x7f000001/
<http://127.0.0.1/>  aren't going to be at much greater risk because of
this.  Users who write down their bank's SSL certificate fingerprint and
paste it by their monitor so they can check it every time they do their
banking will not be at much greater risk because of this.

 

It is something to be concerned about, it is something to patch sooner
rather than later, but I'm not losing a whole lot of sleep over it, and
if someone does manage to make a good solid automated packaging of the
attack before patches are widely distributed I think the most likely
result would be a truly epic rickrolling.

 

That's my $.02.

 

-Joe

 

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave