RE: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
Having been a victim of this issue I can attest to this reported
behaviour. Your failure to reproduce the issue is due to using
different testing methods. Although you are following his reported
testing method, it is important to note that his "do a dns lookup" does
not mean to "perform an nslookup." It is important to note his comment
that "Also of interest is that nslookup didn't use the windows dns
services to send dns requests, but used its own, and so behaved
differently than expolorer or ping." Follow the below to reliable
reproduce the issue.
Go to IE and browse to non-existanthost.localdomain.com (running
nslookup does not result in the response being cached)
Run ipconfig /displaydns to verify that negative acknowledgement is
cached locally on the client
C:\>ipconfig /displaydns
non-existanthost.localdomain.com
----------------------------------------
Name does not exist.
Create DNS records so the entry now exists. You can even place the
entry in the hosts file.
Close browser (or command prompt) and attempt to browse again in IE
again (or attempt to ping host) without running ipconfig /flushdns
C:\>ping non-existanthost.localdomain.com
Ping request could not find host
non-existanthost.localdomain.com. Please check the name and try again.
Run ipconfig /displaydns to verify that negative acknowledgement is
still cached locally on the client.
C:\>ipconfig /displaydns
non-existanthost.localdomain.com
----------------------------------------
Name does not exist.
Run ipconfig /flushdns and then run ipconfig /displaydns to verify the
entry is gone
C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Close browser (or command prompt) and attempt to browse again in IE
again (or attempt to ping host)
C:\>ping non-existanthost.localdomain.com
Pinging non-existanthost.localdomain.com [255.255.255.255] with
32 bytes of data:
-----Original Message-----
From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx]
Sent: Thursday, April 20, 2006 12:39 PM
To: John Biederstedt; Bugtraq
Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately
sabotagedhosts-file lookup
I don't think your issue is with the XP client DNS resolver. If this
consistently fails for you, it must be on the Checkpoint client side.
I've tested this repeatedly in a myriad of different scenarios, and the
resolution has worked exactly as it should in each case.
With the exception of the Checkpoint product (I use ISA, not Checkpoint)
I followed your steps precisely without once experiencing any issues
(other than the failed DNS lookup, which was of course expected.)
I really hope that the Bugtraq moderator decides to post this thread, as
I think it very well exemplifies the need for this type of follow-up
data to be published rather than just the first "Oh, X is broken as well
because of Y" posts. I know this list is extremely difficult to
moderate (I really do,
Dave- just my 2 weeks moderating the MS-Focus list was very time
intensive just from SPAM, even though I may seem a bit intolerant of
things sometimes) but it is critical for people to get full, accurate
bits of data.
I'm not trying to be an ass here (I'm really not) but this specific
issue has come from a post about an "XP DNS client resolver" problem
that was "rotten, yes, surprising, no" to an "according to Microsoft"
being "intended" behavior, to now us seeing that you've most likely got
Checkpoint client problems that have nothing to do with the dnsapi.dll.
We've got no references to anything "according to Microsoft" and now
that we've got detailed information, everyone else on the list can test
this for themselves and see that there isn't an issue.
t
On 4/20/06 8:14 AM, "John Biederstedt" <john@xxxxxxxxxxxxxxx> spoketh to
all:
> In brief:
> need a checkpoint firewall 4.1 or higher. set up a preshared key.
> install client on winXP machine -w- preshared key.
> boot XP box not in target network, but from a remote network connected
> to the Internet via TCP/IP.
> Once connectivity to the Internet is established do a dns lookup of
> something you know will resolve, like www.google.com.
> lookup something within the target network that won't resolve - force
> a failed dns lookup.
> establish a VPN into the checkpoint firewall.
> verify the VPN is working by pinging something in the target network
> that is known to reply to pings, like a DC.
> run a nslookup from previous step of FQDN inside target network.
> enter known values for target FQDN into hosts file.
> try lookup again.
>
> Failed for us consistantly.
>
> I'd be interested in knowing if other have had this problem. We ended
> up pushing a script that ran at VPN setup time that flushed the DNS
> cache. We also pushed a hosts file with the needed FQDNs, since both
> were needed to net nslookups to work right. Also of interest is that
> nslookup didn't use the windows dns services to send dns requests, but
> used its own, and so behaved differently than expolorer or ping. It
> did use the hosts file first, while the windows OS dns services needed
> to have the dns flushed to get rid of the cached failures. We
> observed this by watching traffic and seeing that a windows XP box
> tried twice to resolve a dns query (two requests sent) when using
> nslookup with a different timeout, while the same thing from explorer
> tried four times with a different timeout. Ping resulted in the same
> dns query traffic as expolorer.
>