NANOG36-NOTES 2006.02.13 talk 2 Duane Wessels, DNS cache poisoning
2006.02.13 talk 2 DNS cache poisoners Lazy, Stupid, or Evil Duane Wessels Motivation During March/April 2005, SANS internet storm center reported a number of DNS cache poisoning "attacks" were occurring Poisoned nameservers have bogus NS records for the com zone SANS ISC theorizes it may have been a vector for spyware propagation Microsoft windows (most versions) and symantic firewall products are affected. Slides are on the website, BTW. The poisoning attack: an auth nameserver (where queries normally go) is configured to return bogus and out of baliwick NS auth records. caching resolver receives and trusts those bogus referrals future queries for names in poisoned zone go to the bogus NS dig +trace longislandauction.com will show the poisoned NS auth responses NS auth1.ns.sargasso.net. which has NS com. auth1.ns.sargasso.net. so any caching resolvers may consider auth1.ns.sargasso.net authoritative for any unknowns in com zone. Vulnerable implementations: Windows NT (by default, SP4, can tweak it via reg) Windows 2K, (by default, later fixed) Windows 2003 (not by default, but easy to unfix) Symantec gateway firewalls SYM04-010 and SYM05-010 to Yahoo search and find more. How to find poisoners? start with a large list of DNS names or zones discover set of auth servers for the zone by following referrals on down from root query each auth nameserver compare the NS RR set in each reply to the previously-learned referrals for parent zones this technique only finds parent-zone poisoning. February 2006 Survey input list is about 6 million names from nameservers they have access to. Found 284 "poisoning" nameservers; returns bogus NS entries for root or TLD. . has 217 com 49 net 29 org 24 au 3 cc 2 cn 1 to 1 default 1 some nameservers poison more than one zone. List of some poisoners on slide 12. dns.internic.ca ns1.afternic.com ns0.directnic.com ns1.domainsarefree.com etc. Never attribute to malice what can be adequately to be explained by stupidity Many of the nameservers that return bad referrals appear to be companies in the DNS business registrars resellers speculators typo profiteers others appear to be legitimate companies they should know better many of the names leading to poisoners are either expired or parked Is the sky falling? with so many poisoners out there, why don't we hear more about the problem? Most implementations don't allow root to be poisoned If you were surfing the web with poisoned DNS cache, would you know it? let's simulate it... for every bad referral found, we put the nameserver's IP address go to www.google.com go to www.microsoft.com see what you get. bbns01.secureserver.net, for example, happily pretends to be google.com. dns.domainsatcost.ca is amusing, because their ads are from google, even as they hijack it. a.ns.nameflux.com at least does an HTTP redirect dns2.nai.com doesn't return any A record, so you at least know *something*'s wrong. More examples follow... ns1.frakes.net ns.pairnic.com "smart people use pairnic for DNS"... Duane would beg to differ. 65.75.128.178.com returns an amusing message that is clearly wrong, blaming the clients for the traffic the DNS server itself is causing. Lazy, Stupid, or Evil Laziness: ns1.hi2000.com The admin is too lazy to put each domain delegated to them into separate zone files. Instead, they create a com zone and list A records for each delegation. Laziness such as this is probably the source of most of the poison out there. (includes guess at what their zone file looks like) Stupidity: ns1.frakes.net Typos, combined with laziness, create an interesting situation. Looks like Frakes.net is using the com zone technique, but forgot to make the nameservers fully qualified. Note that ns1.com etc are legitimate DNS names and have A records different than those returned by ns1.frakes.net. Just forgot the dot after the trailing name on the NS record. Evilness: Our definition of an evil poisoning nameserver is one where it answers queries with the wrong address, and maybe proxies web traffic sent there so you get what you (mostly) expect. To help find them, give each source of poison an evilness ranking from 1-5, with one point for each issue below: Returning bad referral poisoning a TLD Answering an A query for "important names" Answering query incorrectly Answering the query such that the web browser looks like it *might* be correct DNS A few fours, no fives. Miscellany Some of the poison sources that we find are actually vulnerable implementations that hve been previously poisoned by someone else. Remember: authoritative nameservers should NEVER accept recursive queries!! Some NS records have non-FQDN names. The name "ns" is a popular example. It's a good thing even the vulnerable implementations don't let the root zone become poisoned. Bottom Line: Several hundred misconfigured nameserves out there that return bad referrals that can poison DNS caches About 75% try to poison root zone, which usually has no effect Probably 90% of nameservers out there today are not vulnerable to this type of poisoning Most attempted poisonings http://dns.measurement-factory.com/surveys/poisoners.html wessels at measurement-factory.com Question from microphone: what do you do when you find these poisoned nameservers? And how often do you run the scripts to avoid false positives? Right now, he doesn't do anything other than put it in the database seen above. He tried contacting one, but never got any answer back. Contacting people is very hit or miss; hard to get responses from people. For second question, he's run the survey a few times; it takes about 10 days to go through the 6 million names, so he might try running it once a month or so. He doesn't think of any cases of "false" positives; they may fix their config, but if it was positive, it's not "false". Applause, and onto the next talk.
participants (1)
-
Matthew Petach