Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup

["Thor (Hammer of God)" <thor () hammerofgod com>]

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