Re: Understanding Kaminsky exploit w/bind
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@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 smime.p7s Description: S/MIME cryptographic signature ___ 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: bind-users Digest, Vol 1499, Issue 1
NAVER - http://www.naver.com/ 신은선(eunsun.s...@nhn.com) 님은 현재 부재중입니다./br 보내신 메일 bind-users Digest, Vol 1499, Issue 1 은 저장되어 있으므로 다시 보내실 필요는 없습니다./br 신은선(eunsun.s...@nhn.com) 님이 남기신 메시지 입니다. 4/15(월)~4/16(화) 개인 휴가입니다.brbr업무 문의는 CDN파트(dl_...@nhn.com)로 연락주시기 바랍니다.brbr감사합니다. ___ 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
I'm having thousands of queries a domain isc.org and this increases my cpu percentage to 100%. That may be happening and how I can control this? is an attack? attachment of the log I made an update to
190.34.55.70 - 201.224.83.242 DNS C isc.org. Internet * ? 190.33.3.27 - 201.224.83.242 DNS C isc.org. Internet * ? 190.32.57.243 - 201.224.83.242 DNS C isc.org. Internet * ? 201.224.149.40 - 201.224.83.242 DNS C isc.org. Internet * ? 190.35.22.44 - 201.224.83.242 DNS C isc.org. Internet * ? 186.73.76.87 - 201.224.83.242 DNS C isc.org. Internet * ? 190.34.44.109 - 201.224.83.242 DNS C isc.org. Internet * ? 190.32.56.118 - 201.224.83.242 DNS C isc.org. Internet * ? 190.34.27.201 - 201.224.83.242 DNS C isc.org. Internet * ? 201.224.115.26 - 201.224.83.242 DNS C isc.org. Internet * ? 190.32.165.139 - 201.224.83.242 DNS C isc.org. Internet * ? 190.33.231.148 - 201.224.83.242 DNS C isc.org. Internet * ? 190.35.84.29 - 201.224.83.242 DNS C isc.org. Internet * ? Thanks a lot! JM ___ 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: bind-users Digest, Vol 1499, Issue 2
NAVER - http://www.naver.com/ 신은선(eunsun.s...@nhn.com) 님은 현재 부재중입니다./br 보내신 메일 bind-users Digest, Vol 1499, Issue 2 은 저장되어 있으므로 다시 보내실 필요는 없습니다./br 신은선(eunsun.s...@nhn.com) 님이 남기신 메시지 입니다. 4/15(월)~4/16(화) 개인 휴가입니다.brbr업무 문의는 CDN파트(dl_...@nhn.com)로 연락주시기 바랍니다.brbr감사합니다. ___ 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: signature expiration
If nothing changes, only the SOA serial will be incremented on resign. The signatures don't 'have' to be renewed every 30 days, you can resign as often as you want / need. regards ~Carlos On 4/11/13 9:14 AM, hugo hugoo wrote: Hello, Can anyone tell me why signatures in dnssec mut be renewed every 30 days? What are the modifications made on a zone with a resign? Thanks in advance for the clarifications. Hugo, ___ 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
Solaris 11
I searched www.isc.orghttp://www.isc.org to no avail. Is bind 9.9.x compatible with Solaris 11? Anything out of the ordinary with compiling and such? Thanks John Manson CAO/HIR/NAF Data-Communications | U.S. House of Representatives | Washington, DC 20515 Desk: 202-226-4244 | TCC: 202-226-6430 | john.man...@mail.house.govmailto:john.man...@mail.house.gov ___ 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: I'm having thousands of queries ...
From: Denis Laventure denis_lavent...@uqac.ca Subject: RE: I'm having thousands of queries a domain isc.org and this increasesmy cpu percentage to 100%. That may be happening and how I can controlthis? is an attack? attachment of the log I made an update to version 9.9.2-P2 as recommended but still continuo I'm having the same problem but for those domains... hao.360.cn. ... 15-Apr-2013 15:00:08.485 security: info: client 117.21.187.20#52538: view e= xternal: query (cache) 'hao.360.cn/A/IN' denied The IP address mentioned in the previous mail message does not seem to be an open recursive resolver. That and the reference to 9.9.2-P2 suggest that RRL would be a good fit and might save CPU cycles. I don't know whether this DNS server is recursive or authoritative, but that log entry suggests at least closed. If it is closed or authoritative, then RRL in the external view would automatically save CPU cycles and bandwidth that would otherwise be spent sending those REFUSED responses. The best by far solution for an open recursive server being hammered (or not yet being hammered) is to close it. If you can't close it and can't afford the fancy defenses of commercial open recursive servers such as https://developers.google.com/speed/public-dns/docs/security#rate_limit RRL is a lot better than no defense. The reason RRL is not recommend for recursives server bcause RRL can slow down browsers, SMTP servers (mail receivers), and other applications that repeat DNS requests. See http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ 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 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 to
