[18684] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Invalid WINS entries

daemon@ATHENA.MIT.EDU (Attonbitus Deus)
Thu Jan 18 13:57:55 2001

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id:  <002601c080e9$3414d650$af05a8c0@anchorsign.com>
Date:         Wed, 17 Jan 2001 16:54:06 -0800
Reply-To: Thor@HAMMEROFGOD.COM
From: Attonbitus Deus <Thor@HAMMEROFGOD.COM>
To: BUGTRAQ@SECURITYFOCUS.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>>
>
>

home help back first fref pref prev next nref lref last post