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@xxxxxxxxxxxxxxxxx [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Dave Korn Sent: Thursday, April 13, 2006 12:29 PM To: full-disclosure@xxxxxxxxxxxxxxxxx Cc: bugtraq@xxxxxxxxxxxxxxxxx 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....
