| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <e1m1pc$sd3$1@sea.gmane.org>
Date: Thu Apr 13 18:29:41 2006
From: davek_throwaway at hotmail.com (Dave Korn)
Subject: 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.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....
Powered by blists - more mailing lists