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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1145546071.6435.259523201@webmail.messagingengine.com>
Date: Thu, 20 Apr 2006 10:14:31 -0500
From: "John Biederstedt" <john@...nsdomain.org>
To: "Thor (Hammer of God)" <thor@...merofgod.com>,
	"Bugtraq" <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately
   sabotagedhosts-file lookup

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.

Download attachment "ReFull-disclosureMicrosoftDNSresolverdeliberatelysabotagedhosts-filelookup.eml" of type "message/rfc822" (2879 bytes)