Understanding Kaminsky exploit w/bind

Mark Elkins mje at posix.co.za
Mon Apr 15 07:57:05 UTC 2013


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?

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6147 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130415/27386201/attachment.bin>


More information about the bind-users mailing list