It doesn't work that way. If you put a bogus BDC on the lan, the server
service won't even start unless its computer account is verified against the
dc based on the SID. Same with putting a bogus PDC with the same domain
name... A workstation won't even set up a secure channel in the first place
unless its account is verified which must happen before the
challenge/response take's place (insofar as NtLmSsp is concerned.)
Granted, you could screw with WINS a bit, but even then the IP stack will
fall back on broadcast to find a 'real' dc if you have properly configured
your node type to 0x8 (Hybrid). If you are already on the LAN to the point
of doing all this stuff, just capture SMB packets over a few days---
---------------------------------
Attonbitus Deus
[EMAIL PROTECTED]
----- Original Message -----
From: "Byrne, David" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 17, 2001 1:35 PM
Subject: Invalid WINS entries
> After playing around with some WINS problems we were having, I discovered
> something that doesn't seem to bother very many people. WINS does nothing
to
> verify the 1Ch (domain controllers) registrations sent to it. This allows
an
> attacker to overwrite some or all of the Domain Controllers in the record.
> The new entries could be pointing at a box that will participate in the
> logon process long enough to capture user names and passwords. If the
> passwords are only hashed with LanMan (not NTLM), they can be easily
broken
> with L0phtCrack. A less malicious problem can occur if someone brings up a
> server that incorrectly thinks it is a Domain Controller. Although the
> server cannot participate in the domain, it will register itself with WINS
> in the 1Ch record and workstations will still send logon requests to it.
>
> The best work around I could think of is to use static entries for records
> that are sensitive (there are probably more besides 1Ch). Domain
Controllers
> shouldn't be changed very often, so the management work would be minimal.
> When I contacted Microsoft, I was told that they were aware of this, but
did
> not consider it a significant problem. They confirmed that static records
> were the best solution.
>
> Attached is a PERL script that can demonstrate the problem. Use it
> cautiously.
>
>
> David Byrne, MCSE
> TIAA CREF
>
> <<wins2.pl>>
>
>
