Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
From: "Thor (Hammer of God)" <thor () hammerofgod com>
Date: Sat, 15 Apr 2006 11:39:18 -0700


It's a simple method to bypass malicious host file modification.  Probably
in response to malware like MyDoom, which specifically altered the hosts
file to keep clients from accessing AV sites ( go.microsoft.com was also
specifically included in MyDoom as well.)


I agree that there should have been better documentation of this, but I
think the noted objections are a bit hyperbolic.  (Or as Dr. Tom Shinder
would say, a "Creative Interpretation.")

Statements like "deliberately sabotaged,"corrupting the resolver," and
"intentional dsn poisoning" sound like something Steve Gibson would say.
It's a local hosts-file entry filter, and is in the API.

Malware hosts-file modification is common-- it makes sense for Microsoft to
do this, though again, it would have been nice to see this functionality
mentioned in the SP2 documentation.  If administrators are really freaked
about this, then they can block in their own internal DNS, proxies,
firewalls, etc... This boils down to a "home user" issue, and thus, I think
the decision to create exceptions was smart.

If one doesn't want auto-updates on, then turn them off.  I don't think
host-entries are a smart way of blocking updates anyway.  While it's
unfortunate that the OP wasted a lot of his time trying to do this, one
should note that a google for [turn off media player updates] returned
KB278960 as the top hit.

While I find the behavior interesting and feel it should be documented (it
may be, actually... But I couldn't find anything in my MSDN Library or
google) it is clearly by design, and IMHO, nothing more than an attempt to
thwart the actively-exploited practice of malware modification of the hosts
file, and not more Evil Empire Conspiracy.

t






On 4/13/06 12:01 PM, "Derek Soeder" <dsoeder () eeye com> spoketh to all:

Dave, great find!  Those lists you dug up are named DomainScreenList and
HostsScreenList in the symbols for DNSAPI; here they are for
reference...

DomainScreenList:

  windowsupdate.microsoft.com
  windowsupdate.com
  microsoftupdate.com
  download.microsoft.com
  update.microsoft.com

HostsScreenList:

  microsoft.com
  www.microsoft.com
  support.microsoft.com
  wustats.microsoft.com
  microsoftupdate.microsoft.com
  office.microsoft.com
  msdn.microsoft.com
  go.microsoft.com
  msn.com
  www.msn.com
  msdn.com
  www.msdn.com

A quick check suggests that this behavior debuted with XP SP2, and is
present on 2003 SP1 as well.  (I haven't looked at 2003 RTM, but it
would be interesting if someone please would.)  Although one could argue
that this measure is intended to thwart attempts to block updating
Microsoft products, it's indefensible because:

 1) It's a point-in-time, cat-and-mouse defense against an ephemeral
malware technique, a change that causes permanent headaches in
situations like yours, and the potential for negative publicity as a
result.

 2) As far as I know, their malicious software removal tool didn't exist
back when this behavior was created, so what good was keeping access to
Microsoft open going to do an infected system?  What good does it do to
install a patch for a vulnerability that's already been exploited onto
the computer of the archetypal "home user"?

 3) Although it falls in line with removing raw sockets and limiting
half-open TCP connections, making these Microsoft hosts and domain
unfilterable is even more egregious because of the implications you
mentioned, and because this behavior was never publicly documented.

 4) Their selectiveness seems unfair.  I'm sure all the
antivirus/antispyware companies whose domains regularly end up in
hosts-files would love to be added to the list, too.  (So would everyone
else whose software reports "anonymous usage statistics" and all the
other companies making money from web advertising.*)  Going back to #3,
it would have been more disruptive but less controversial if they had
removed regard for the hosts-file entirely, or made the resolver only
consult the hosts-file after all else failed, thereby preventing it from
being used for blocking.  It's not a great analogy, but this move is
sort of like if they had only blocked raw IP packets headed for a
Microsoft IP address, instead of raw sockets entirely.

Like those other XP SP2 changes mentioned above, there does not appear
to be a way to disable this hosts-file screening behavior through
configuration.

-- Derek




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]