Re: Invalid WINS entries

[Attonbitus Deus <Thor () HAMMEROFGOD COM>]

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
Thor () HammerofGod Com

----- Original Message -----
From: "Byrne, David" <dbyrne () TIAA-CREF ORG>
To: <BUGTRAQ () SECURITYFOCUS COM>
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>>