Re: Invalid WINS entries

[Russ <Russ.Cooper () RC ON CA>]

-----BEGIN PGP SIGNED MESSAGE-----

My take is this isn't a security issue.

WINS is definitely not a security mechanism, WINS is a replacement
for NBNS, or NetBIOS Name Services from Ungermann-Bass and the late
80's LANMAN environments. Its strictly intended to prevent the old
broadcast storms some of us may remember having to fire-fight.

The fact that the NT Domain Authentication environment relies upon
NetBIOS machine types (e.g. 1Ch) to determine whom to direct logon
attempts to is not a security design, but simply the LANMAN-way. It
was never secure from hijacking unless everyone was polite and didn't
do what you noticed (implemented in Samba by Ashton/Leighton/Allison
so Samba could participate *correctly* in an NT Domain).

NTLMv2 and the various options it makes available, such as
SMB-signing, was intended to thwart MITM attacks and spoofing of
things like 1Chs, but it doesn't affect the basic operation of WINS.
If you allow dynamic registrations then a WINS server will accept a
broadcast of any server type and add its record.

The question is only whether or not such a record will be used by
clients.

The election process for PDCs in an NT environment assumes that all
parties are cooperating. If they do, then the process goes smoothly.
Whomever responds first to the election call basically wins the
election. Since all parties are supposedly looking at the same
election results, they're supposed to back off when they see they're
not the winner. Your observations of the reaction of a valid PDC, one
that knows it won the election, to an insistent PDC saying it still
holds the token is consistent with registry tweaks available to force
one NT box to be PDC in an environment where two NT boxes believe,
honestly, they're both PDC. NT 3.5/3.51 in WAN environments
notoriously corrupted Domain Master Browser/Segment Master Browser
tables with or without WINS which sometimes required forcing a PDC by
some means other than elections.

Ergo, NT ended up with a failover mechanism built in to deal with
such insistence. Of course it expected the insistence to come from
another NT box, not a Samba server (and a *normal* Samba server will
behave appropriately).

If you rely upon WINS to enforce your authentication realm then you
are sorely misguided. Anyone who installed Win95's first releases
into NT Domains has probably experienced the unreliability of WINS to
maintain Browse Masters and, by extension, the loss of an
authenticating DC due to a conflicting client broadcast. There are
good reasons why MS dropped further WINS development.

Static entries only prevent entries from being over-written, they
don't prevent the arguments between an insistent box (e.g. a
mal-configured Samba Server or an errant Win9x box) and those that
believe themselves to be who they think they are. They won't prevent
boxes from disappearing from the network, or segments from believing
someone other than the WINS server. They can also cause other
problems. NT 4.0 SP4 introduced the ability to immediately delete
dynamic WINS entries (not available through WINS Manager prior to
SP4, only via a tool called WINSCL.exe), or Tombstone out dynamic
WINS entries that aren't desired (or malicious attempts to DoS a DC
via WINS). For more details, see;

http://support.microsoft.com/support/kb/articles/Q184/6/93.asp

SMB-signing, OTOH, can make NT/W2K-only environments resistant to
this type of tampering (not the WINS servers, but the client's being
fooled into talking to someone other than the *real thang*).

> First, I think you're right about the secure channel for NT, but
> does this apply to 9x as well?

No, 9x machines don't have machine accounts in NT domains and don't
use a secure channel prior to authentication.

> Second, even though a bogus DC won't participate in a domain, it
> will still register itself in the 1C record.

Not sure how you can describe something as a "bogus DC". You can set
up a Samba server to be a DC in an NT Domain, nothing bogus about it.
Anything can advertise itself as a NetBIOS 1C and have it registered
in the WINS dB, WINS does nothing to verify that the machine
advertising itself is, in fact, what it claims to be (in terms of
serviceability), unless of course NTLMv2/SMB-signing is enabled.

That aside, you should also realize the way WINS servers return 1Ch
entries when queried. Basically, if the WINS server is a DC then it
will return its own address as the first address the querying client
should try, followed by up to 24 additional DC addresses it knows
about in order according to date and time of registration (oldest
first).

Ergo, your attack is thwarted if the WINS server is also a DC for the
domain that the client is attempting to auth to. For more details,
see;

http://support.microsoft.com/support/kb/articles/Q167/3/65.asp

> I also disagree that an H-node configuration is "properly
> configured". NetBIOS broadcasts only allow you to query your network
> segment (assuming you aren't forwarding broadcasts). This system
> might work fine in a
> small environment, but P-node is the only way to go for an
> enterprise scale operation.

Couple of problems here. H-node uses P-node first, and falls back to
B-node when a NBNS (WINS) registration fails. Ergo, if I can't get to
the WINS server I'm still allowed to get to the network. P-node only
would prevent your networking from initializing if your WINS server
was inaccessible (due to a router down, server unavailable,
whatever). In an Enterprise environment its far more likely that the
WINS server might not be accessible than in a small environment, ergo
I'd argue that P-node only is most applicable in small environments
rather than enterprise size. H-node will minimize the support calls.
H-node configured clients that fail on P-node will continue to retry
registration with the unavailable WINS server until it becomes
available, using B-node in the meantime. For more details, see;

http://support.microsoft.com/support/kb/articles/q119/4/93.asp

Further, NetBIOS clients will still rely upon local Browse Masters
regardless of what WINS tells them. After registering themselves with
the WINS server, they won't go back to it unless they need to resolve
a name they don't have in their cache already. Anything on the same
segment as the client will be in its cache and, therefore, not
require a WINS query. See the section titled "How WINS works" at the
bottom of;

http://support.microsoft.com/support/kb/articles/q119/4/93.asp

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2

iQCVAwUBOmf+LxBh2Kw/l7p5AQHifwP/SnuFczSOZ37EyZg6JE/a+MiKoYnZofW7
OILdGcrZczxBfbc4ZTgNPTz1gjNNshhh5CBdwerYB6FPqXGe57AO4W/YI6uI/cl2
l56dq7gMTxzPXez0GGFCe+eur1NyKmqMzQPHzVua2GJLkgwCqExYwaeLysmvh6lO
mKuwUd85QVM=
=wiaW
-----END PGP SIGNATURE-----