Re: Does anyone remember ...
Are you drinking? XD On Sat, Nov 17, 2018 at 11:54 PM Red Cricket wrote: > Does anyone remember a project involving DNS at UCS where someone set up a > dns server(s) to do arithmetic? If so can you reply with a link or > something? > > Thanks > ___ > 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
Re: Understanding Kaminsky exploit w/bind
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. 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
Re: Understanding Kaminsky exploit w/bind
On Mon, Apr 15, 2013 at 9:44 AM, Jamie Ostrowski jamie.ostrow...@gmail.comwrote: 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
Understanding Kaminsky exploit w/bind
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. 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
