Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhost

Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
Date: Wed, 19 Apr 2006 20:54:46 -0700

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.
 
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.

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


<Prev in Thread] Current Thread [Next in Thread>