Understanding Kaminsky exploit w/bind

Mon Apr 15 14:44:28 UTC 2013

On Mon, Apr 15, 2013 at 2:57 AM, Mark Elkins <mje at posix.co.za> wrote:

> On Sun, 2013-04-14 at 21:30 -0500, Jamie Ostrowski wrote:
> >
> >
> >
> >  Hello,
> >
> >
> >  I hope this isn't too off-topic, but I've been studying the Kaminsky
> > DNS exploit and I have a question.
> >
> >
> >  According to what I've read on the topic, the Kaminsky exploit
> > hijacks a whole domain, and that you can launch the attack on a
> > nameserver over and over. It seems to imply you can do this
> > immediately before waiting for any TTL's to expire by using a series
> > of random name queries, however, I don't see how that is possible, and
> > I wonder if anyone can explain this.
> >
> >
> >  I fired up a recursive nameserver running bind 9.4. In another window
> > I started running a tcpdump session listening for traffic on port 53.
> >
> >
> >   If I perform a query on one of my domains the first time, for
> > nonexistant-host.mydomain.com, I can see my nameserver querying the
> > roots, getting a referral to the auth. nameserver for mydomain.com,
> > and then seeing the query go out to that authoritative nameserver.
> >
> >
> >  That makes sense.
>
>
> >   However, if I then fire off another query, for
> > nonexistant-host2.mydomain.com, I do not see another querying going
> > out to find the auth nameserver for mydomain.com - because it is
> > cached in my recursive resolver.
>
> >   This also makes sense.
>
> Not looking again for the authoritative NameServers for "mydomain.com"
> makes sense but not seeing *any* queries - that is - for
> "nonexistant-host2.mydomain.com" does not. Unless you are also somehow
> authoritative for mydomain.com - how would you already know the answer
> to "nonexistant-host2.mydomain.com" ??? Why would an answer for that
> query already be cached?
>
>
  No, the authoritative NS record for mydomain.com is cached. It still does
send out a query to the cached auth. nameserver looking up the A record for
nonexistant-host2.

But that is the point of my question. Since it is relying on it's cached
entry for the auth. nameserver for mydomain.com, the attacker, once the
auth. nameserver for mydomain.com was cached, would have to wait until that
cached NS entry for mydomain.com expires from the resolver's cache before
they can make another attempt to send a forged NS record for mydomain.com,
correct?

> Kaminsky works because it looks for random stuff that most people would
> not put in their zone (so it will not have be previously cached,
> positively or negatively) - so it has to be looked up by asking an
> appropriate authoritative server.
>
>
Understood. But once the first random host is looked up, if the 'bad guy'
launching the attack did not beat the response from the 'good guy', then
the true NS record for the domain would be kept in the resolver's cache
until the TTL expires.

If you try another random host before that NS record in the cache expires,
it's just going to go ask the correct nameserver for the entry.

So as far as I see it, you would have to wait for that cached NS entry for
the domain to expire before you have another chance. Yet, the documentation
I found at:

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html#shenanigansv2

"
*Step 1* — bad guy client requests a *random name* within the target domain
(*www12345678.bankofsteve.com*), something unlikely to be in cache even if
other lookups for this domain have been done recently.

   -

   *Step 2a* — As before, the bad guy sends a stream of forged packets to
   the victim, but instead of *A* records as part of an Answer, it instead
   delegates to another nameserver via Authority records. "I don't know the
   answer, but you can ask over there".

   The authority data may well contain the "real"
*bankofsteve.com*nameserver hostnames, but the glue
   *points those nameservers at badguy IPs*. This is the crucial poisoning,
   because a Query ID match means that the victim believes that badguy's
   nameservers are authoritative for *bankofsteve.com*.

   The bad guy now *owns the entire zone*.
   "

In this example, it works if the resolver does not already have the correct
cached glue records for bankofsteve.com. But what if the resolver DOES have
the correct glue records for ns1.bankofsteve.com cached? The attacker will
have to wait until that TTL expires before he has another chance to poison
the glue, correct? I don't see how you can launch another random hostname
lookup that would be successful until the glue record entries for
ns1.bankofsteve.com expire in the resolver's cache.

> You don't use Kaminsky directly on the authoritative server for the
> domain that you are trying to inject false information about - it
> already knows what exists and by definition - what does not exist.
>
>

> >   But then how is it that an attacker, after he sends his first query
> > for a non-existant host, if they aren't able to guess the transaction
> > id to spoof a response before the real response comes in, then won't
> > the resolver have the cached NS records for that mydomain.com stored
> > with a TTL?
> >
> >
> >   I don't see how you can then launch successive queries for other
> > non-existant hosts until the cached TTL expires for the domain
> > server.
> >
> >
> >   If anyone can shed any light, I'd appreciate it. I've read several
> > articles on this topic and it's a piece of the puzzle I've been
> > stumped on.
> >
> >
> >    Thanks!
> >
> >
> >    - Jamie
> >
> >
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
>   .  .     ___. .__      Posix Systems - (South) Africa
>  /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
> / |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130415/4fabafe1/attachment.html>