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