FW: BigRed.com - cache poisoning for com/net/org domains (SOLVED)

Mike Batchelor mikebat at tmcs.net
Wed Jul 18 00:58:02 UTC 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have determined how my Windows 2000 DNS cache got poisoned, resulting in
non-existent domains resolving instead to the bigred.com website.

There are two registered hosts, NS1.REFRACT.COM (66.34.52.240) and
NS2.REFRACT.COM (66.34.52.241) that are authoritative for some 543 domains
under the generic TLDs.  The list of domains is in the attached text file,
for those who are interested (thanks to Joseph McDonald <joe at vpop.net> for
grepping his copies of the gTLD zone files at my request).  The addresses
given are the ones in the glue from the gTLD servers.  REFRACT.COM is
registered through OpenSRS with NS[1-4].MYDOMAIN.COM as nameservers. 
Mydomain.com's servers give different addresses for NS[12].REFRACT.COM,
65.194.192.211 and 65.194.192.212, respectively.  In practice, modern DNS
software ignores the glue from the delegated-to nameservers, preferring to
cache the glue from the parents, in this case, the gTLD servers.  But even
so, nameservers are in fact running on the addresses given in the REFRACT.COM
zone by the Mydomain.com servers, and they behave the same way as described
here.

A DNS cache, following delegations from the roots, and the gTLD servers, for
one of these domains, will encounter bogus glue in the responses to
_iterative_ queries made to one of these poison servers.  The bogus glue
assigns false address records to [a-m].gtld-servers.net, assigning
66.34.52.224 to all of them.  Depending on the state of the already-cached
records for the gTLD server addresses, a naive DNS cache, such as Windows
2000 DNS server in its default setup, or very old BIND servers prior to
~4.9.1, may become poisoned by caching this bogus data.  When that happens,
future queries for gTLD domains will be directed to the server at
66.34.52.224.

This bogus gTLD server at 66.34.52.224 is the one that responds to any
_iterative_ query with the IP address of the bigred.com search engine
website.

It's rather simple to get a client of a vulnerable cache to make a query for
one of the domains registered with the REFRACT.COM nameservers.  HTML spam
will do the trick.

I emphasize _iterative_ query, because all these servers - all four
NS[12].REFRACT.COM servers and 66.34.52.224 - are lame for any domain when
given a recursive query.  They simply give a referral back to the roots, with
correct glue.  A poor schmuck (like me) who is trying to track down the
source of his Win2K cache poison, would encounter the bogus gTLD glue in his
cache's answers, and would naturally query the server at the bogus address to
see what is going on. But the common query tools perform recursive queries
unless told otherwise.  Caches use iterative queries to resolve domains for
their clients.  That these poison servers respond with bogus glue only to
iterative queries is slightly clever, and provides a little cover while DNS
caches continue to be poisoned.  It confused me for a while in any case!  I
couldn't have done it better myself, even if I were Eugene Kashpureff.

For Windows 2000 DNS, the solution is to click on the "Advanced" tab on the
Properties screen of the DNS server control panel, and check the box labelled
"Secure cache against pollution".  Duh.  Why this is not on by default ... ah
why bother: it's Microsoft, just be glad it's there, for gods' sakes.  Once
your Win2K cache is a little less naive, you can flush the cache in the same
control panel, and your DNS resolution should return to normal.  No more
bigred.com when you'd expect a "Cannot find server or DNS Error" page, no
more replies to ping from hosts that don't exist, etc.  Older BIND software
simply must be replaced with a modern version that has some kind of poison
protection.  D. J. Bernstein's dnscache was never vulnerable, since it always
tosses out-of-zone glue.

I hope this proves useful to someone.  I searched all over many search
engines, and found a handful of references to the problem in various
(sometimes funny) contexts, but no solution or explanation.  Hopefully this
message will be archived and easily found on Google, and the next poor
schmuck that tries to solve this problem will find this post and save himself
a few days' hair-pulling.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBO1TfGUksS4VV8BvHEQIJXQCgoGXUsOBZ+PjgPbbwdMe39Pj/3hMAoK8p
NJB5lesgwY1HyBnl4PUsuvYK
=geCR
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: refract_domains.txt
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20010717/a8659fab/attachment.txt>


More information about the NANOG mailing list