North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
NANOG36-NOTES 2006.02.13 talk 2 Duane Wessels, DNS cache poisoning
2006.02.13 talk 2
DNS cache poisoners
Lazy, Stupid, or Evil
During March/April 2005, SANS internet storm
center reported a number of DNS cache poisoning "attacks"
Poisoned nameservers have bogus NS records for the com zone
SANS ISC theorizes it may have been a vector for spyware
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
caching resolver receives and trusts those bogus referrals
future queries for names in poisoned zone go to the
dig +trace longislandauction.com
will show the poisoned NS auth responses
NS com. auth1.ns.sargasso.net.
so any caching resolvers may consider auth1.ns.sargasso.net
authoritative for any unknowns in com zone.
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
some nameservers poison more than one zone.
List of some poisoners on slide 12.
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
others appear to be legitimate companies
they should know better
many of the names leading to poisoners are either expired
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
doesn't return any A record, so you at least know
More examples follow...
ns.pairnic.com "smart people use pairnic for DNS"...
Duane would beg to differ.
returns an amusing message that is clearly wrong,
blaming the clients for the traffic the DNS server
itself is causing.
Lazy, Stupid, or Evil
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)
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
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
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.
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
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.
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
Probably 90% of nameservers out there today are not
vulnerable to this type of poisoning
Most attempted poisonings
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
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
Applause, and onto the next talk.