Message-ID: <A641CEADDBAEAE4C96FC5BF854695268ECB659@av-mail01.corp.int-eeye.com>
Date: Thu, 13 Apr 2006 12:01:38 -0700
From: "Derek Soeder" <dsoeder@...e.com>
To: <bugtraq@...urityfocus.com>
Subject: RE: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup


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


* At least msads.net wasn't hard-coded into the DLL, but why msn.com?


-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Dave
Korn
Sent: Thursday, April 13, 2006 12:29 PM
To: full-disclosure@...ts.grok.org.uk
Cc: bugtraq@...urityfocus.com
Subject: [Full-disclosure] Microsoft DNS resolver: deliberately
sabotaged hosts-file lookup


  Hey, guess what I just found out:  Microsoft have deliberately
sabotaged their DNS client's hosts table lookup functionality.

  Normally you can override DNS lookup by specifying a hostname and IP
directly in the hosts file, which is searched before any query is issued
to your dns server; this technique is often used to block ads, spyware
and phone-homes by aliasing the host to be blocked to 127.0.0.1 in your
hosts file.

  Since recent versions of media player only offer you the choice to
check for updates once per day/week/month, but not "Don't check at all",
I thought I'd try to block it in my hosts file.  This used to be easy,
you just needed to block windowsmedia.com and www.windowsmedia.com in
your hosts file and then media player couldn't phone home to check.

  I tried that at first, but it didn't work: media player kept on
telling me that there was an update (I'm still on v9 and it wants me to
move up to v10) available.  So I assumed they'd changed the URL, and ran
strings on wmplayer.exe, which found the URL
http://go.microsoft.com/fwlink/?LinkId=9996
embedded in the executable; on visiting it in my browser, it redirected
to
http://www.microsoft.com/windows/windowsmedia/player/download/download.a
spx
which is an update page for wmplayer.

  So I added '127.0.0.1   go.microsoft.com' to my hosts file, flushed 
everything out, and tried again.  To my great irritation, wmplayer still
managed to connect and find out that there was an update available.  I
wasted a bunch of time looking to see if there was some other URL hidden
in there, but then I found the staggering truth:

  Microsoft DNS client special-cases 'go.microsoft.com' and refuses to
look it up in the hosts file.

  As evidence, here's the contents of the hosts file, and output from
ipconfig and ping, showing clearly that 'go.microsoft.com' is singled
out for hosts-file bypass, whereas 'g.microsoft.com' (which is in fact a
real hostname in the DNS) and 'goo.microsoft.com' (which is not) are
successfully resolved from the hosts file.

------------------------------<snip!>------------------------------
[...]
------------------------------<snip!>------------------------------

  The fact that only one of these three nearly-identical names fails is
all the evidence it takes to convince me that this is deliberate
sabotage by Microsoft of the resolver's standard functionality.

  This is yet another example of the sheer breathtaking arrogance of
Microsoft's belief that they have the right to control your computer and
misdirect the normal flow of operations if they believe doing so to be
in their own financial advantage.  I'm gobsmacked by this: corrupting
the resolver is little short of an intentional dns poisoning attack.
It's as if internet explorer had special code in it to see if you were
doing an internet search for 'microsoft products' and then altered the
results to only return favourable reviews that microsoft wanted you to
see.  It's as if excel looked out to see if you were doing financial
calculations relating to TCO of microsoft products and fiddled the
figures to look more favourable. 
It's essentially corrupt, and it's not being done for /our/ benefit.

  No wonder their warranty always excludes any guarantee that the
software will perform as described, when they know perfectly well that
they have deliberately designed it to perform NOT as described but
according to secret specs that have nothing to do with the functionality
as described.

  I'm running fully up-to-date Windows XP SP2.  I don't have any pfw
software that could conceivably be interfering, and the windows firewall
is running with more-or-less the default settings (I've only added a
couple of exceptions, no other changes).  I don't think this is a false
positive.

  On reading through %WINDIR%\system32\dnsapi.dll with 'strings', I find
the following hostnames listed.  I assume they are all also singled out
for special treatment:-

www.msdn.com
msdn.com
www.msn.com
msn.com
go.microsoft.com
msdn.microsoft.com
office.microsoft.com
microsoftupdate.microsoft.com
wustats.microsoft.com
support.microsoft.com
www.microsoft.com
microsoft.com
update.microsoft.com
download.microsoft.com
microsoftupdate.com
windowsupdate.com
windowsupdate.microsoft.com

[  I've verified that the same behaviour occurs for
office.microsoft.com, exactly as for go.microsoft.com, but haven't tried
any of the others yet. 
I'd bet real money on it, though.  ]

    cheers,
      DaveK
--
Can't think of a witty .sigline today.... 

Powered by blists - more mailing lists