Discussion:
Microsoft DNS resolver: deliberately sabotaged hosts-file lookup
Dave Korn
2006-04-13 17:29:15 UTC
Permalink
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.aspx
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!>------------------------------
C:\WINDOWS\system32\drivers\etc>type hosts
# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
127.0.0.1 www.windowsmedia.com
127.0.0.1 windowsmedia.com
127.0.0.1 g.microsoft.com
127.0.0.1 go.microsoft.com
127.0.0.1 goo.microsoft.com
127.0.0.1 goober.microsoft.com


C:\WINDOWS\system32\drivers\etc>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\WINDOWS\system32\drivers\etc>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost


Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : www.windowsmedia.com


Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : windowsmedia.com


Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : g.microsoft.com


Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : goo.microsoft.com


Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : goober.microsoft.com


goober.microsoft.com
----------------------------------------
Record Name . . . . . : goober.microsoft.com
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


goo.microsoft.com
----------------------------------------
Record Name . . . . . : goo.microsoft.com
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


www.windowsmedia.com
----------------------------------------
Record Name . . . . . : www.windowsmedia.com
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


g.microsoft.com
----------------------------------------
Record Name . . . . . : g.microsoft.com
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


windowsmedia.com
----------------------------------------
Record Name . . . . . : windowsmedia.com
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1



C:\WINDOWS\system32\drivers\etc>ping g.microsoft.com

Pinging g.microsoft.com [127.0.0.1] with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time=761ms TTL=128
Reply from 127.0.0.1: bytes=32 time=-761ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time=-761ms TTL=128

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = -761ms, Average = 1073741633ms

C:\WINDOWS\system32\drivers\etc>ping goo.microsoft.com

Pinging goo.microsoft.com [127.0.0.1] with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time=761ms TTL=128
Reply from 127.0.0.1: bytes=32 time=761ms TTL=128
Reply from 127.0.0.1: bytes=32 time=761ms TTL=128
Reply from 127.0.0.1: bytes=32 time=761ms TTL=128

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 761ms, Maximum = 761ms, Average = 761ms

C:\WINDOWS\system32\drivers\etc>ping go.microsoft.com

Pinging www.go.microsoft.akadns.net [207.46.196.55] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 207.46.196.55:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\WINDOWS\system32\drivers\etc>
------------------------------<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....



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Brandon S. Allbery KF8NH
2006-04-13 17:36:40 UTC
Permalink
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately sabotaged
their DNS client's hosts table lookup functionality.
I thought this was part of avoiding malware attempts to block Windows
Update.
--
brandon s. allbery [linux,solaris,freebsd,perl]
***@kf8nh.com
system administrator [openafs,heimdal,too many hats]
***@ece.cmu.edu
electrical and computer engineering, carnegie mellon university
KF8NH



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Stan Bubrouski
2006-04-13 18:59:18 UTC
Permalink
Post by Brandon S. Allbery KF8NH
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately sabotaged
their DNS client's hosts table lookup functionality.
I thought this was part of avoiding malware attempts to block Windows
Update.
How bypassing blocking of go.microsoft.com affects windowsupdate I
don't know. Been a while since I looked at windows update at all, but
doesn't it download files from mirrors anyways? And even if it didn't
are the files actually downloaded from go.microsoft.com? Either way
it appears Dave is right, which makes me wonder if there isn't another
greater purpose aside form WMP updates. Like assured tracking of
users for other nefarious and monopolistic purposes.

Best Regards,
sb
Post by Brandon S. Allbery KF8NH
--
brandon s. allbery [linux,solaris,freebsd,perl]
system administrator [openafs,heimdal,too many hats]
electrical and computer engineering, carnegie mellon university
KF8NH
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Dave Korn
2006-04-13 18:59:21 UTC
Permalink
Post by Brandon S. Allbery KF8NH
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately sabotaged
their DNS client's hosts table lookup functionality.
I thought this was part of avoiding malware attempts to block Windows
Update.
Perhaps so; do you have a reference? I found

http://support.microsoft.com/?scid=kb;en-us;836941

which was last reviewed seven days ago, and contains advice about how to
"Remove entries for Windows Update and Microsoft Update from the hosts
file", and no slightest hint of any suggestion that these entries could not
possibly make any difference even if they tried.

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



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
J.A. Terranson
2006-04-14 03:32:03 UTC
Permalink
Post by Brandon S. Allbery KF8NH
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately
sabotaged their DNS client's hosts table lookup functionality.
I thought this was part of avoiding malware attempts to block Windows
Update.
Windows *IS* malware. To block it requires reformatting.
--
Yours,

J.A. Terranson
***@mfn.org
0xBD4A95BF


'The right of self defence is the first law of nature: in most governments
it has been the study of rulers to confine this right within the narrowest
limits possible. Wherever standing armies are kept up, and the right of
the people to keep and bear arms is, under any colour or pretext
whatsoever, prohibited, liberty, if not already annihilated, is on the
brink of destruction.'

St. George Tucker

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Jamie Riden
2006-04-16 02:32:29 UTC
Permalink
Post by Brandon S. Allbery KF8NH
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately sabotaged
their DNS client's hosts table lookup functionality.
I thought this was part of avoiding malware attempts to block Windows
Update.
In that case, they should allow us to add symantec et al - it's not
much use having Windows Update working while the machine is happily
rootkitted. Grepping hosts files across campus for 127.0.0.1 ...
liveupdate.symantec.com - or your local equivalent - can prove
interesting.

If it was a feature, I'd expect there to be ways to add to the list of
pass-through domains, or ways to disable it.

cheers,
Jamie
--
Jamie Riden / ***@europe.com / ***@computer.org
"Microsoft: Bringing the world to your desktop - and your desktop to
the world." -- Peter Gutmann
A***@lboro.ac.uk
2006-04-13 19:05:27 UTC
Permalink
hi,

...makes me wonder what happens if/when they need to change the
IP address of go.microsoft.com

many many people have already been burnt by the hardcoding of
addresses/IPs into their applications.


a

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
dumdidumdideldey
2006-04-13 03:39:57 UTC
Permalink
hi
Post by A***@lboro.ac.uk
hi,
...makes me wonder what happens if/when they need to change the
IP address of go.microsoft.com
many many people have already been burnt by the hardcoding of
addresses/IPs into their applications.
thats the point. its not the ip which is hardcoded. its the
fqdn which is extempted from being lookud up in the local
hosts-file.
DaveK is absolutely right with his expressions about this behaviour.
i neither do believe this is an attempt to prevent some malware
from interrupting ms-autoupdate. you see ... even microsoft
would never be that shortsighted!!! (errm ... at least i hope so)

virtual

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Joachim Schipper
2006-04-14 00:13:21 UTC
Permalink
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately sabotaged
their DNS client's hosts table lookup functionality.
(...) I'd try to block (Windows Media Player) it in my hosts file.
Microsoft DNS client special-cases 'go.microsoft.com' and refuses to look
it up in the hosts file.
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. ]
What's your point? It's not like it's the first piece of software ever
to bypass the hosts file, is it? And if you're a software giant, that's
easy to do at a lower level.

Blacklisting IP addresses by /etc/hosts or equivalent is an extremely
broken way of blocking, anyway; and vague hacks like that need not be
supported. Use a real, non-host-based firewall.

Of course, you might wish to stop certain software from phoning home.
Fine, but use something that works - MS is evil in many ways, but not
because this particular hack happens not to work.

Switching to OSS quite nicely solves all these problems, though.

Joachim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Mario Contestabile
2006-04-19 15:56:53 UTC
Permalink
Fyi, Any NT app can bypass the local hosts file using DnsQuery(...,...,
DNS_QUERY_NO_HOSTS_FILE, ...);




***@computer.org
http://bubbler.net/outlaw/blog




-----Original Message-----
From: Joachim Schipper [mailto:***@math.uu.nl]
Sent: April 13, 2006 8:13 PM
To: full-***@lists.grok.org.uk; ***@securityfocus.com
Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately
sabotaged hosts-file lookup
Post by Dave Korn
Hey, guess what I just found out: Microsoft have deliberately
sabotaged their DNS client's hosts table lookup functionality.
(...) I'd try to block (Windows Media Player) it in my hosts file.
Microsoft DNS client special-cases 'go.microsoft.com' and refuses to
look it up in the hosts file.
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.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Duncan Simpson
2006-01-03 16:35:42 UTC
Permalink
Nobody has mentioned this, so maybe I should.

It is not difficult to bypass the hosts file on *any* operting system
whatsoever, by just writing your own resolver. This is easier than you
think---the standard resolver library has all the machinery you need modulo
creating the UDP socket. Bind has an even easier library... and an example of
how to use it (aka dig).

AFAIK winodws update et al are based on http, so a firewall that requiries one
to use the provided HTTP proxy can block its requests (and lots of instant
messgaing software). You could even use a transparent proxy so nobody notices
anything until the proxy denies their request.

You can do all the above with a solution like sonic wall (and presuambly their
competitors' alternatives), linux+iptables, and presumably similar faciltiies
on other platforms.

I think the advice is to buy or build a seperate firewall, configure it to
deny anything not desired, and you should be safe. Rerquiring the use of a
local proxy or name servers just requires blocking outbound requests to the
appropriate ports from all other hosts. I suspect bugtraq would *not*
recommend any seperate firewall based on M$ windows, but would recommend using
the provided firewalling feattures.
--
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."
Nick FitzGerald
2006-04-20 08:04:28 UTC
Permalink
Post by Mario Contestabile
Fyi, Any NT app can bypass the local hosts file using DnsQuery(...,...,
DNS_QUERY_NO_HOSTS_FILE, ...);
"Any NT app" ???

http://msdn.microsoft.com/library/en-us/dns/dns/
dnsquery.asp?frame=true

...

Windows 2000 Server and Windows 2000 Professional: This value is
not supported.

Of course, what the dox say and what works may be two different
things...


Regards,

Nick FitzGerald

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Derek Soeder
2006-04-13 19:01:38 UTC
Permalink
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-***@lists.grok.org.uk
[mailto:full-disclosure-***@lists.grok.org.uk] On Behalf Of Dave
Korn
Sent: Thursday, April 13, 2006 12:29 PM
To: full-***@lists.grok.org.uk
Cc: ***@securityfocus.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....
Thor (Hammer of God)
2006-04-15 18:39:18 UTC
Permalink
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
Post by Derek Soeder
Dave, great find! Those lists you dug up are named DomainScreenList and
HostsScreenList in the symbols for DNSAPI; here they are for
reference...
windowsupdate.microsoft.com
windowsupdate.com
microsoftupdate.com
download.microsoft.com
update.microsoft.com
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
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
Ansgar -59cobalt- Wiechers
2006-04-17 23:06:22 UTC
Permalink
Post by Thor (Hammer of God)
It's a simple method to bypass malicious host file modification.
Make that "pointless method" and it's correct. To modify the hosts file
(or its location) malware would need administrative privileges. With
admin privileges the malware can do whatever it pleases, including but
not limited to bypassing or replacing the entire DNS resolver.

Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Paul Wouters
2006-04-17 20:49:14 UTC
Permalink
Post by Thor (Hammer of God)
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.)
Sure. And instead of everyone whining about this, they should prepare
their DNSSEC setup so microsoft can secure their zone and can rely on
the resolver to use DNSSEC to prevent these types of malware traps.

Paul
Geo.
2006-04-17 17:09:28 UTC
Permalink
Post by Thor (Hammer of God)
I agree that there should have been better documentation of this, but I
think the noted objections are a bit hyperbolic.
While I don't disagree with what you said, I think there are some things you
didn't consider.

First, why is anything besides what is required for windows update being
bypassed? Why MSN.COM? Why NOT Symantec.com? I mean this looks more like a
way to keep passport functional than as a way to foil trojans.

Second, why is it that it's darn near impossible to screw with media player
or Messenger (both are protected by Windows file protection) yet hosts file
changes don't even popup a dialog box to ask the user if the change is ok? I
mean this is a really sneaky way of "fixing" things. Also before you say WFP
or a popup could be disabled by a trojan, so could this fix.

Third, this appears to me to be just more half witted fixes imo. The problem
is a trojan modifying hosts then fix the problem instead of ignoring hosts.
Provide a locking mechanism for hosts, remove the trojan, there are a
hundred ways to fix this that are far more proper ways to do things than
this.

Geo.
Thor (Hammer of God)
2006-04-20 03:54:46 UTC
Permalink
Post by Geo.
Post by Thor (Hammer of God)
I agree that there should have been better documentation of this, but I
think the noted objections are a bit hyperbolic.
While I don't disagree with what you said, I think there are some things you
didn't consider.
First, why is anything besides what is required for windows update being
bypassed? Why MSN.COM? Why NOT Symantec.com? I mean this looks more like a
way to keep passport functional than as a way to foil trojans.
Because, as many users choose to use MSN as their portal to the internet via
the MSN browser included in many OEM installations (just like many use AOL.)
Many people log on to email, passport, music purchases, etc via portal on
MSN and MSDN. It is to keep hosts file entries from taking users to
phishing sites where they may enter credentials that could be stolen.

It's not Microsoft's job to protect Symantec customers. That's Symantec's
job. Microsoft is not in control of Symantec assets or hostnames. They are
in control of Microsoft's assets and hostnames. It would make no sense to
build in host list exceptions for hostnames you have no control over. And
we both know that if they DID include other exceptions for assets that they
did not control that everyone with cry foul over that as well, because it's
Microsoft.
Post by Geo.
Second, why is it that it's darn near impossible to screw with media player
or Messenger (both are protected by Windows file protection) yet hosts file
changes don't even popup a dialog box to ask the user if the change is ok? I
mean this is a really sneaky way of "fixing" things. Also before you say WFP
or a popup could be disabled by a trojan, so could this fix.
Because "hosts" is a simple text file that is designed to be edited and
maintained by the administrator of the machine. It's supposed to change.
Wmplayer.exe automatically replaces itself with an authoritative cached copy
to ensure that it is not Trojaned. It's a good thing. And so what if a
Trojan could disable it (even though dnsapi.dll is also protected)?? Let
it-- but make it have to do it - more for it to do. A kernel mode rootkit
could disable everything it wanted to - why not just give up and turn off
your machine?

This is really simple. MyDoom altered the hosts file so people couldn't hit
go.microsoft.com, so they added an exception list for their sites. The
reason it wasn't documented was so that malware authors wouldn't know to
bypass it, but now some do. Oh well, worked for a while.
Post by Geo.
Third, this appears to me to be just more half witted fixes imo. The problem
is a trojan modifying hosts then fix the problem instead of ignoring hosts.
Provide a locking mechanism for hosts, remove the trojan, there are a
hundred ways to fix this that are far more proper ways to do things than
this.
They do. There is more information on how to secure a Windows box than
anything else out there. They give you free malware removal tools. They'll
be giving you free AV. They DO all these things, yet people continue to
open .exe's in email attachments. It's defense in depth. It's good.

t
Geo.
2006-04-20 12:18:40 UTC
Permalink
Post by Thor (Hammer of God)
MSN and MSDN. It is to keep hosts file entries from taking users to
phishing sites where they may enter credentials that could be stolen.
So you agree with me, that it's more for passport functionality than to
allow trojaned users to get to windows update.
Post by Thor (Hammer of God)
It's not Microsoft's job to protect Symantec customers.
No it's not, it's Microsoft's job to protect windows users, millions of who
use NortonAV. But it would seem that MS is more interested in protecting
their user tracking information than the users.
Post by Thor (Hammer of God)
Because "hosts" is a simple text file that is designed to be edited and
maintained by the administrator of the machine.
It would be trivial to create a hosts editing GUI interface that could
manage a protected hosts file. Does anyone but me long for the days of the
NT team where they wouldn't do something if they couldn't do it right? I
mean what's next, they going to modify firewall settings if the user has
locked out features that are required for windowsupdate or passport to work?
Post by Thor (Hammer of God)
This is really simple. MyDoom altered the hosts file so people couldn't hit
go.microsoft.com, so they added an exception list for their sites.
The right way to fix it would have been to ask the user before bypassing
hosts since by your own statements hosts is a file for the administrator to
manage. Perhaps the admin put MS sites in hosts files to keep his users from
updating components on their own?
Post by Thor (Hammer of God)
The reason it wasn't documented was so that malware authors wouldn't know
to
Post by Thor (Hammer of God)
bypass it, but now some do. Oh well, worked for a while.
Oh please lets not justify sneaky stuff that affects a users security
settings by saying it had to be done sneaky so the hackers wouldn't know,
the hackers figure this stuff out in seconds. Just mark this as a stupid
idea and add a popup before it bypasses values in the hosts file so the user
is allowed to permit or deny it. Had they done that I would have defended
their actions, it's when they mess with a users security without asking that
I find it inappropriate behavior for a company like MS.

Geo.
Thor (Hammer of God)
2006-04-24 16:15:50 UTC
Permalink
Response in-line: and the last one unless someone can post something
intelligent on the matter...
Post by Geo.
Post by Thor (Hammer of God)
MSN and MSDN. It is to keep hosts file entries from taking users to
phishing sites where they may enter credentials that could be stolen.
So you agree with me, that it's more for passport functionality than to
allow trojaned users to get to windows update.
Um, no, I don't agree with you in the least. It's not "more for passport
functionality." Passport does not need to by-pass host entries to function.
We've already gone over what the behavior is for, but that doesn't seem to
matter to you.
Post by Geo.
Post by Thor (Hammer of God)
It's not Microsoft's job to protect Symantec customers.
No it's not, it's Microsoft's job to protect windows users, millions of who
use NortonAV. But it would seem that MS is more interested in protecting
their user tracking information than the users.
Oh, I see now. It's about tracking users now, is it? So you're saying that
the exception list in dnsapi.dll is not only there for some super-secret
Passport "functionality" but now Microsoft is using it to protect "their
user tracking information?" Brilliant. I suppose that the next argument
will be that dnsapi.dll contains the secret as to where that one sock goes
after it's lost in the dryer, right? Hey! Maybe that's what winsock really
is!!
Post by Geo.
Post by Thor (Hammer of God)
Because "hosts" is a simple text file that is designed to be edited and
maintained by the administrator of the machine.
It would be trivial to create a hosts editing GUI interface that could
manage a protected hosts file. Does anyone but me long for the days of the
NT team where they wouldn't do something if they couldn't do it right? I
mean what's next, they going to modify firewall settings if the user has
locked out features that are required for windowsupdate or passport to work?
Trivial, huh? Get right on that, then. If it's trivial, then write it up
and post it. Of course, malware would only have to use the same hook that
the GUI does. But you might have something here. Let's see, rather than a
simple exception list, you'd rather have a "protected" hosts file that
requires a special GUI for administrators to use to manage host entries and
that would require additional API's for DNS to access it as well as other
3rd party functions, huh? Administrators would have read/write, but users
would only be able to read it, right? Yep, all you have to do is whip up a
nifty GUI that performs the proper token permission checking as well as
file-level permissions. Utterly ridiculous, and it still does nothing to
prevent malware abuse.
Post by Geo.
Post by Thor (Hammer of God)
This is really simple. MyDoom altered the hosts file so people couldn't
hit go.microsoft.com, so they added an exception list for their sites.
The right way to fix it would have been to ask the user before bypassing
hosts since by your own statements hosts is a file for the administrator to
manage. Perhaps the admin put MS sites in hosts files to keep his users from
updating components on their own?
Post by Thor (Hammer of God)
The reason it wasn't documented was so that malware authors wouldn't know
to bypass it, but now some do. Oh well, worked for a while.
Oh please lets not justify sneaky stuff that affects a users security
settings by saying it had to be done sneaky so the hackers wouldn't know,
the hackers figure this stuff out in seconds. Just mark this as a stupid
idea and add a popup before it bypasses values in the hosts file so the user
is allowed to permit or deny it. Had they done that I would have defended
their actions, it's when they mess with a users security without asking that
I find it inappropriate behavior for a company like MS.
Let me get this straight: After creating the magic GUI for hosts
management, Microsoft is to prompt the user with a pop-up that says
"Attention Stupid Administrator: We are about to bypass the hosts file
entry for MSDN so that we can track your user information, ensure that
Passport functionality is maintained, as so that we can search for that sock
you lost in the dryer last week. Are you sure that you don't want us to not
do that? Please click YES, NO, or MAYBE."

That would make it less stupid?

t
r***@hotmail.com
2006-04-17 09:38:51 UTC
Permalink
After reading your scary message, went to verify your points and confirmed all. Whilst, as I've been running a real software firewall (Sunbelt Kerio Personal Firewall is for free) on top of a router firewall, I've been able to block or force a request as I see fit for each of these sites. On WMP, untick the Automatic Coded update function for starters, but indeed its highly irritating that you have no control over auto update yes/no. As to the MS firewall, that's a joke. It only does partial incoming traffic control and NONE on outgoing!!!!! If you like blocking specific IP's or ranges use for instance Peerguardian 2. I find it stops truly anything you don't want to not to come thru.

The bypassing of the HOSTS file is something i thinks would fall under required disclosure....changing functionality of an intergral part to network control. Think this build in trickery will have interest of the EU commission too!
j***@johnsdomain.org
2006-04-17 12:33:18 UTC
Permalink
The XP DNS client has other problems as well. It caches DNS failiures (arguably out of spec with the RFC, BTW), screwing up VPNs if you're VPNed into an internet network that has local domains which need to resolve to RFC1918 addresses. The cached failed lookups get prefered to forced entries in the hosts file, if that is tried as a way of forcing the dns lookups to work. Very frustrating. So, this isn't much of a surprise. Rotten, yes, surprising, no.
Thor (Hammer of God)
2006-04-19 22:22:32 UTC
Permalink
Then you've hosed your XP install. XP does not resolve cached addresses
before the hosts file.

Ping your 1918 domain controller. Add a bogus entry for the FQDN of the
same machine. Ping it again. Hosts file overrides. I'm not sure what you
mean by "DNS failiures" though. Please post something we can all use to
test your rotten but unsurprising behavior.

Oh, and before getting very frustrated, even in your hosed install, just try
a "IPCONFIG /flushdns" next time.


t
Post by j***@johnsdomain.org
The XP DNS client has other problems as well. It caches DNS failiures
(arguably out of spec with the RFC, BTW), screwing up VPNs if you're VPNed
into an internet network that has local domains which need to resolve to
RFC1918 addresses. The cached failed lookups get prefered to forced entries
in the hosts file, if that is tried as a way of forcing the dns lookups to
work. Very frustrating. So, this isn't much of a surprise. Rotten, yes,
surprising, no.
John Biederstedt
2006-04-19 23:43:38 UTC
Permalink
Actually, according to microsoft, the dns client in XP was *intended* to
check to see if a dns lookup had failed earlier before going to the
hosts file.

We did ping the internal domain controller, added the bogus FQDN, and
tried again. None of that worked, because prior to the VPN working, and
lookup of the domain controller had failed, and been cached. So,
because the failiure was checked before the hosts file, once the VPN was
up, the dns lookups didn't work.

Oh yes, the XP install was factory Dell.
Thor (Hammer of God)
2006-04-20 02:59:40 UTC
Permalink
You got a KB or some other official reference? I just did it again after a
failed DNS looked. Lookup failed, added it in the hosts file, worked just
fine.

What exactly do you mean by "dns lookup failed?" The server is not
available, or the host isn't found on the server? I just tested both ways -
valid server with invalid host and invalid server. Ping resolution failed,
added host, resolved immediately and attempted ping, removed it and saved,
ping resolution immediately failed again; just like it is supposed to.

As I requested in my previous post, please provide us with detailed
instructions on how to recreate this issue.

t
Post by John Biederstedt
Actually, according to microsoft, the dns client in XP was *intended* to
check to see if a dns lookup had failed earlier before going to the
hosts file.
We did ping the internal domain controller, added the bogus FQDN, and
tried again. None of that worked, because prior to the VPN working, and
lookup of the domain controller had failed, and been cached. So,
because the failiure was checked before the hosts file, once the VPN was
up, the dns lookups didn't work.
Oh yes, the XP install was factory Dell.
John Biederstedt
2006-04-20 15:14:31 UTC
Permalink
In brief:
need a checkpoint firewall 4.1 or higher. set up a preshared key.
install client on winXP machine -w- preshared key.
boot XP box not in target network, but from a remote network connected
to the Internet via TCP/IP.
Once connectivity to the Internet is established do a dns lookup of
something you know will resolve, like www.google.com.
lookup something within the target network that won't resolve - force a
failed dns lookup.
establish a VPN into the checkpoint firewall.
verify the VPN is working by pinging something in the target network
that is known to reply to pings, like a DC.
run a nslookup from previous step of FQDN inside target network.
enter known values for target FQDN into hosts file.
try lookup again.

Failed for us consistantly.

I'd be interested in knowing if other have had this problem. We ended
up pushing a script that ran at VPN setup time that flushed the DNS
cache. We also pushed a hosts file with the needed FQDNs, since both
were needed to net nslookups to work right. Also of interest is that
nslookup didn't use the windows dns services to send dns requests, but
used its own, and so behaved differently than expolorer or ping. It did
use the hosts file first, while the windows OS dns services needed to
have the dns flushed to get rid of the cached failures. We observed
this by watching traffic and seeing that a windows XP box tried twice to
resolve a dns query (two requests sent) when using nslookup with a
different timeout, while the same thing from explorer tried four times
with a different timeout. Ping resulted in the same dns query traffic
as expolorer.
Thor (Hammer of God)
2006-04-20 17:38:38 UTC
Permalink
I don't think your issue is with the XP client DNS resolver. If this
consistently fails for you, it must be on the Checkpoint client side.

I've tested this repeatedly in a myriad of different scenarios, and the
resolution has worked exactly as it should in each case.

With the exception of the Checkpoint product (I use ISA, not Checkpoint) I
followed your steps precisely without once experiencing any issues (other
than the failed DNS lookup, which was of course expected.)

I really hope that the Bugtraq moderator decides to post this thread, as I
think it very well exemplifies the need for this type of follow-up data to
be published rather than just the first "Oh, X is broken as well because of
Y" posts. I know this list is extremely difficult to moderate (I really do,
Dave- just my 2 weeks moderating the MS-Focus list was very time intensive
just from SPAM, even though I may seem a bit intolerant of things sometimes)
but it is critical for people to get full, accurate bits of data.

I'm not trying to be an ass here (I'm really not) but this specific issue
has come from a post about an "XP DNS client resolver" problem that was
"rotten, yes, surprising, no" to an "according to Microsoft" being
"intended" behavior, to now us seeing that you've most likely got Checkpoint
client problems that have nothing to do with the dnsapi.dll. We've got no
references to anything "according to Microsoft" and now that we've got
detailed information, everyone else on the list can test this for themselves
and see that there isn't an issue.

t
Post by John Biederstedt
need a checkpoint firewall 4.1 or higher. set up a preshared key.
install client on winXP machine -w- preshared key.
boot XP box not in target network, but from a remote network connected
to the Internet via TCP/IP.
Once connectivity to the Internet is established do a dns lookup of
something you know will resolve, like www.google.com.
lookup something within the target network that won't resolve - force a
failed dns lookup.
establish a VPN into the checkpoint firewall.
verify the VPN is working by pinging something in the target network
that is known to reply to pings, like a DC.
run a nslookup from previous step of FQDN inside target network.
enter known values for target FQDN into hosts file.
try lookup again.
Failed for us consistantly.
I'd be interested in knowing if other have had this problem. We ended
up pushing a script that ran at VPN setup time that flushed the DNS
cache. We also pushed a hosts file with the needed FQDNs, since both
were needed to net nslookups to work right. Also of interest is that
nslookup didn't use the windows dns services to send dns requests, but
used its own, and so behaved differently than expolorer or ping. It did
use the hosts file first, while the windows OS dns services needed to
have the dns flushed to get rid of the cached failures. We observed
this by watching traffic and seeing that a windows XP box tried twice to
resolve a dns query (two requests sent) when using nslookup with a
different timeout, while the same thing from explorer tried four times
with a different timeout. Ping resulted in the same dns query traffic
as expolorer.
n***@my.house
2006-04-16 15:40:53 UTC
Permalink
Obnoxious, sure, but not hard to beat. (Assuming for some insane reason you are actually still using Windows for anything other than playing games)

You just add an entry in your DNS server with a zone matching the hostname that you want to override. And if they have the IP addresses of MSFT-controlled DNS servers hardcoded, you just add an iptables (or equivalent) entry in your firewall (note - this is a seperate device than your wintendo PC, not a peice of software running on your PC)
s***@rtr.ca
2006-04-16 18:54:10 UTC
Permalink
Just take a binary editor to dnsapi.dll and change the strings to .ccc instead of .com

That should fix it, until the next update cycle.
Thor (Hammer of God)
2006-04-19 22:00:23 UTC
Permalink
Nope. It's a protected file. Change it, or delete it, and it will come
right back. Windows automatically restores protected system files to prevent
corruption or alteration by malware.

t
Post by s***@rtr.ca
Just take a binary editor to dnsapi.dll and change the strings to .ccc instead of .com
That should fix it, until the next update cycle.
s***@mailinator.com
2006-04-16 17:15:53 UTC
Permalink
FYI: go.microsoft.com is used to point to security bulletins.

In fact, all the domains listed with the exception of MSN.com are used in the Windows and Office patching process.
Sean Scott
2006-04-24 16:10:09 UTC
Permalink
Having been a victim of this issue I can attest to this reported
behaviour. Your failure to reproduce the issue is due to using
different testing methods. Although you are following his reported
testing method, it is important to note that his "do a dns lookup" does
not mean to "perform an nslookup." It is important to note his comment
that "Also of interest is that nslookup didn't use the windows dns
services to send dns requests, but used its own, and so behaved
differently than expolorer or ping." Follow the below to reliable
reproduce the issue.


Go to IE and browse to non-existanthost.localdomain.com (running
nslookup does not result in the response being cached)
Run ipconfig /displaydns to verify that negative acknowledgement is
cached locally on the client

C:\>ipconfig /displaydns

non-existanthost.localdomain.com
----------------------------------------
Name does not exist.

Create DNS records so the entry now exists. You can even place the
entry in the hosts file.
Close browser (or command prompt) and attempt to browse again in IE
again (or attempt to ping host) without running ipconfig /flushdns

C:\>ping non-existanthost.localdomain.com

Ping request could not find host
non-existanthost.localdomain.com. Please check the name and try again.

Run ipconfig /displaydns to verify that negative acknowledgement is
still cached locally on the client.

C:\>ipconfig /displaydns

non-existanthost.localdomain.com
----------------------------------------
Name does not exist.

Run ipconfig /flushdns and then run ipconfig /displaydns to verify the
entry is gone

C:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Close browser (or command prompt) and attempt to browse again in IE
again (or attempt to ping host)

C:\>ping non-existanthost.localdomain.com

Pinging non-existanthost.localdomain.com [255.255.255.255] with
32 bytes of data:


-----Original Message-----
From: Thor (Hammer of God) [mailto:***@hammerofgod.com]
Sent: Thursday, April 20, 2006 12:39 PM
To: John Biederstedt; Bugtraq
Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately
sabotagedhosts-file lookup

I don't think your issue is with the XP client DNS resolver. If this
consistently fails for you, it must be on the Checkpoint client side.

I've tested this repeatedly in a myriad of different scenarios, and the
resolution has worked exactly as it should in each case.

With the exception of the Checkpoint product (I use ISA, not Checkpoint)
I followed your steps precisely without once experiencing any issues
(other than the failed DNS lookup, which was of course expected.)

I really hope that the Bugtraq moderator decides to post this thread, as
I think it very well exemplifies the need for this type of follow-up
data to be published rather than just the first "Oh, X is broken as well
because of Y" posts. I know this list is extremely difficult to
moderate (I really do,
Dave- just my 2 weeks moderating the MS-Focus list was very time
intensive just from SPAM, even though I may seem a bit intolerant of
things sometimes) but it is critical for people to get full, accurate
bits of data.

I'm not trying to be an ass here (I'm really not) but this specific
issue has come from a post about an "XP DNS client resolver" problem
that was "rotten, yes, surprising, no" to an "according to Microsoft"
being "intended" behavior, to now us seeing that you've most likely got
Checkpoint client problems that have nothing to do with the dnsapi.dll.
We've got no references to anything "according to Microsoft" and now
that we've got detailed information, everyone else on the list can test
this for themselves and see that there isn't an issue.

t
Post by John Biederstedt
need a checkpoint firewall 4.1 or higher. set up a preshared key.
install client on winXP machine -w- preshared key.
boot XP box not in target network, but from a remote network connected
to the Internet via TCP/IP.
Once connectivity to the Internet is established do a dns lookup of
something you know will resolve, like www.google.com.
lookup something within the target network that won't resolve - force
a failed dns lookup.
establish a VPN into the checkpoint firewall.
verify the VPN is working by pinging something in the target network
that is known to reply to pings, like a DC.
run a nslookup from previous step of FQDN inside target network.
enter known values for target FQDN into hosts file.
try lookup again.
Failed for us consistantly.
I'd be interested in knowing if other have had this problem. We ended
up pushing a script that ran at VPN setup time that flushed the DNS
cache. We also pushed a hosts file with the needed FQDNs, since both
were needed to net nslookups to work right. Also of interest is that
nslookup didn't use the windows dns services to send dns requests, but
used its own, and so behaved differently than expolorer or ping. It
did use the hosts file first, while the windows OS dns services needed
to have the dns flushed to get rid of the cached failures. We
observed this by watching traffic and seeing that a windows XP box
tried twice to resolve a dns query (two requests sent) when using
nslookup with a different timeout, while the same thing from explorer
tried four times with a different timeout. Ping resulted in the same
dns query traffic as expolorer.
Loading...