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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ