tag:blogger.com,1999:blog-4088979.post8088812845334080053..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Thoughts on Latest Kaminsky DNS IssueRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-4088979.post-26217473014174396022009-02-10T03:50:00.000-05:002009-02-10T03:50:00.000-05:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-22258501857637540452008-07-14T14:20:00.000-04:002008-07-14T14:20:00.000-04:00The best theory I've seen running around the full-...The best theory I've seen running around the full-disclosure and DailyDave lists has to do with ICMP unreachable responses to DNS server queries. I'm sure I'lll massacre the details, so I won't try to explain them here, but I'm sure the archives on seclists.org and elsewhere for the last couple days will have good info.<BR/><BR/>Unfortunately, Dan otherwise left us in the dark for a month, so we can only guess at the details for now. I don't think it would detract from his talk if he had given details along with the patch/vuln release, nor sell any less tickets to BH. But hey, it's his discovery, he can do what he wants with it, especially as big as it seems to be. :)Unknownhttps://www.blogger.com/profile/15357840241031190415noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-57388101161792740222008-07-10T17:46:00.000-04:002008-07-10T17:46:00.000-04:00richard, could you please find out tomorrow how th...richard, could you please find out tomorrow how the countermeasures influnce detection of fast-flux networks? <BR/>i had to chancel my attendance at dimva :/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-36945021996416187122008-07-10T13:19:00.000-04:002008-07-10T13:19:00.000-04:00Certainly a fascinating black-hat method. Thanks ...Certainly a fascinating black-hat method. Thanks very much for the information... I wouldn't have heard of this otherwise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-65907159464146891132008-07-10T12:30:00.000-04:002008-07-10T12:30:00.000-04:00Anonymous- The UDP packets that trigger the poison...Anonymous- The UDP packets that trigger the poisoning can be spoofed to be coming from your allowed IPs. <BR/><BR/>Now if the allowed IPs are just a local subnet then you can use a firewall to prevent those spoofed packets from even getting in the network in the first place.Nick Dielhttps://www.blogger.com/profile/00355512234242049870noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-22907632661225449952008-07-10T12:18:00.000-04:002008-07-10T12:18:00.000-04:00Augusto is right. Dan most likely found a way to b...Augusto is right. Dan most likely found a way to better guess the transaction ID. The source port has always been trivial, Phil even showed the configuration file which shows how a DNS server can be configured to always use source port 53.<BR/><BR/>Most likely it will be shown the transaction ID isn't sufficient at 16 bits and a random source port will add the randomness needed...for now. We really needs DNSSec.<BR/><BR/>The SANS paper referenced by the Register really doesn't shed any light on this subject. DNS Poisoning is just mentioned as an attack vector and doesn't claim the transaction ID increases by one.<BR/><BR/>DNS Poisoning and the randomness of transaction IDs have been discussed for a long time (see the 2002 paper, "DNS Cache Poisoning - The Next Generation by Joe Stewart"). Now we probably have a model that shows 16 bits is not big enough.<BR/><BR/>Nick<BR/><A HREF="http://packetpi.blogspot.com/2008/07/dns-poisoning.html" REL="nofollow">DNS Poisoning</A>Nick Dielhttps://www.blogger.com/profile/00355512234242049870noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-75058266121095364922008-07-10T12:16:00.000-04:002008-07-10T12:16:00.000-04:00This comment has been removed by the author.Nick Dielhttps://www.blogger.com/profile/00355512234242049870noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-25985900390348821312008-07-10T11:32:00.000-04:002008-07-10T11:32:00.000-04:00If you are running BIND, check your named.conf (or...If you are running BIND, check your named.conf (or equivalent file) very carefully after updating it.<BR/><BR/>Any lines like<BR/><BR/> query-source port 53;<BR/> query-source-v6 port 53;<BR/><BR/>need to be commented out or deleted so that forwarded DNS queries come from random ports.<BR/><BR/>If you run selinux, make sure your selinux polices are updated to handle queries coming from BIND on ports other than 53.<BR/><BR/>Check that your firewall isn't allowing queries out to the net from port 53 only too.<BR/><BR/>PhilPhilhttps://www.blogger.com/profile/05789761931551673481noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-65877650573618482872008-07-10T11:05:00.000-04:002008-07-10T11:05:00.000-04:00Name fixed, thank you!Name fixed, thank you!Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-26870745708502493002008-07-10T10:57:00.000-04:002008-07-10T10:57:00.000-04:00If I do not allow recursive queries from untrusted...If I do not allow recursive queries from untrusted (read: my) IP addresses, doesn't that limit the attackers to those in my trusted IP's? No recursion, no cache?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-42647015711023305982008-07-09T23:28:00.000-04:002008-07-09T23:28:00.000-04:00It seems something like this has been written abou...It seems something like this has <A HREF="http://www.theregister.co.uk/2008/07/09/dns_bug_student_discovery/" REL="nofollow">been written about</A> before.Jamie Levyhttps://www.blogger.com/profile/16089000750284843256noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-31991113719117777122008-07-09T17:56:00.000-04:002008-07-09T17:56:00.000-04:00Augusto shut the fuck up you got owned hahahahahaAugusto shut the fuck up you got owned hahahahahaAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-68548022854580956952008-07-09T16:50:00.000-04:002008-07-09T16:50:00.000-04:00Baranov would be right if there wasn't a Transacti...Baranov would be right if there wasn't a Transaction ID that also needed to be spoofed. Trans IDs are usually randomized, so it seems that Dan found an effective way of finding the right TransID because of the lack of source port randomization. It's not just finding the right port number.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-77546124027137701342008-07-09T15:57:00.000-04:002008-07-09T15:57:00.000-04:00I think the correct spelling is "Dan Kaminsky."I think the correct spelling is "Dan Kaminsky."Anonymousnoreply@blogger.com