Understanding Kaminsky exploit w/bind

Tue Apr 16 02:21:15 UTC 2013

On Mon, Apr 15, 2013 at 9:44 AM, Jamie Ostrowski
<jamie.ostrowski at gmail.com>wrote:

>
>
>
> 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.
>
>
>
>   I realize my question was probably not formed very well, but I did find
the answer I was looking for. I learned that the cached entries for the
nameservers can be overwritten, even though their TTL's have not expired.
This wasn't explained in the various illustrations I've found on this
attack.

>
>
>
>
>
>
>> 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/fb3c1fc4/attachment-0001.html>