On Mon, Apr 15, 2013 at 9:44 AM, Jamie Ostrowski <jamie.ostrow...@gmail.com>wrote:
> > > > On Mon, Apr 15, 2013 at 2:57 AM, Mark Elkins <m...@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@lists.isc.org >> > https://lists.isc.org/mailman/listinfo/bind-users >> >> -- >> . . ___. .__ Posix Systems - (South) Africa >> /| /| / /__ m...@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@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
