[18681] in bugtraq
Re: Invalid WINS entries
daemon@ATHENA.MIT.EDU (3APA3A)
Thu Jan 18 13:18:09 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19773360466.20010118130429@sandy.ru>
Date: Thu, 18 Jan 2001 13:04:29 +0300
Reply-To: 3APA3A <3APA3A@SECURITY.NNOV.RU>
From: 3APA3A <3APA3A@SECURITY.NNOV.RU>
X-To: "Byrne, David" <dbyrne@TIAA-CREF.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <F1E50062AEB5D411971E002035710A7318B8D6@MSXDENUSR01>
Dear Byrne, David,
While adding new Windows NT workstation into NT domain workstation and
PDC do key exchange. Same process is between domains in trust
relationships. This keys are used to establish secure channel for user
authentication. Keys prevents attack you described.
The only situation your scenario works is user logon from Windows
95/98 host. This is known, documented problem.
BTW, it looks like NT queries WINS about DC only in case it can't
contact DC which does last authentication and there is no DC's in
local network and it doesn't depend on node type.
MS recommends to filter WINS traffic to prevent WINS from any DoS and
spoofing attacks.
18.01.2001 0:35, you wrote: Invalid WINS entries;
B> After playing around with some WINS problems we were having, I discovered
B> something that doesn't seem to bother very many people. WINS does nothing to
B> verify the 1Ch (domain controllers) registrations sent to it. This allows an
B> attacker to overwrite some or all of the Domain Controllers in the record.
B> The new entries could be pointing at a box that will participate in the
B> logon process long enough to capture user names and passwords. If the
B> passwords are only hashed with LanMan (not NTLM), they can be easily broken
B> with L0phtCrack. A less malicious problem can occur if someone brings up a
B> server that incorrectly thinks it is a Domain Controller. Although the
B> server cannot participate in the domain, it will register itself with WINS
B> in the 1Ch record and workstations will still send logon requests to it.
B> The best work around I could think of is to use static entries for records
B> that are sensitive (there are probably more besides 1Ch). Domain Controllers
B> shouldn't be changed very often, so the management work would be minimal.
B> When I contacted Microsoft, I was told that they were aware of this, but did
B> not consider it a significant problem. They confirmed that static records
B> were the best solution.
B> Attached is a PERL script that can demonstrate the problem. Use it
B> cautiously.
B> David Byrne, MCSE
B> TIAA CREF
B> <<wins2.pl>>
--
Vladimir Dubrovin Sandy, ISP
Sandy CCd chief Customers Care dept
http://www.sandy.ru Nizhny Novgorod, Russia
http://www.security.nnov.ru
