Home page logo
/

nanog logo nanog mailing list archives

NANOG36-NOTES 2006.02.13 talk 2 Duane Wessels, DNS cache poisoning
From: Matthew Petach <mpetach () netflight com>
Date: Mon, 13 Feb 2006 08:54:25 -0800

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.

  By Date           By Thread  

Current thread:
  • NANOG36-NOTES 2006.02.13 talk 2 Duane Wessels, DNS cache poisoning Matthew Petach (Feb 13)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]