Date: Thu, 20 Apr 2006 10:38:38 -0700
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: John Biederstedt <john@...nsdomain.org>,
	Bugtraq <bugtraq@...urityfocus.com>
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@...nsdomain.org> 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.
> 

Powered by blists - more mailing lists