Tech Off Thread

6 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

HOSTS problem or %WINDIR%\system32\dnsapi.dll

Back to Forum: Tech Off
  • User profile image
    Beetlejuice

    http://www.securityfocus.com/archive/1/431027/30/0/threaded

    BODY of page:

    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!>------------------------------
    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/

  • User profile image
    Cannot​Resolve​Symbol

    Well, you wouldn't exactly want malware using the hosts file to redirect Microsoft's update sites to their own servers to install more malware.  Seems like a reasonable behavior to me.

  • User profile image
    phreaks

    Beetlejuice wrote:
    http://www.securityfocus.com/archive/1/431027/30/0/threaded

    BODY of page:

    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.


    WMP apparantly doesn't use the hosts file, so what?
    What is your point, seriously?

    So you are arguing that WMP bypassing the host file == deliberate sabotage of MS's DNS host table lookup?

    I don't understand the logic with that argument.

  • User profile image
    nlondon

    I don't normally interject into these types of threads, but you have to agree that if a virus or trojan did what CannotResolveSymbol suggests, then we'd all get a long, rambling dissertation on how aweful it is microsoft update was vulnerable to a "simple" host file attack.

    Please at least consider the possiblity that functionality like that has been thought through carefully by Microsoft.  Condemn it only when you know all the facts.

  • User profile image
    Maurits

    nlondon wrote:
    if a virus or trojan did what CannotResolveSymbol suggests, then we'd all get a long, rambling dissertation on how aweful it is microsoft update was vulnerable to a "simple" host file attack.


    Editing the host file requires administrative privilege.  If a virus can do that, you're already hosed.

  • User profile image
    maniac78

    Most users are adminsitrators. So it is a problem.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.