OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NT Domain DoS and Security Exploit with SAMBA Server
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NT Domain DoS and Security Exploit with SAMBA Server


  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: NT Domain DoS and Security Exploit with SAMBA Server
  • From: Paul L Schmehl <paulsUTDALLAS.EDU>
  • Date: Tue, 2 Mar 1999 16:43:10 -0600
  • Approved-By: Russ.CooperRC.ON.CA
  • Reply-To: Paul L Schmehl <paulsUTDALLAS.EDU>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

Near the end of November of last year, we notified the SAMBA team,
NTBUGTRAQ and Microsoft of two problems with SAMBA in an NT domain.  The
first was a DoS issue and the second was a logon security issue.

Since that time, we have been corresponding with the Microsoft Security
Response Team and doing extensive testing with SAMBA in a test NT
domain.

Here's our test network parameters:
NT 4.0 SP4 PDC
NT 4.0 SP4 BDC
RedHat Linux 5.1 with SAMBA 1.9.18p5
Windows NT Workstation client
Windows 98 client

Here's the issues:

DoS:
*************
When a SAMBA server is placed in a NT domain and configured as follows in
the smb.conf file:

security=server
password server=[hostname of PDC]
domain controller=[hostname of PDC]
domain logons=yes

domain logons will fail if the PDC is rebooted while the SAMBA server is
still running.  We haven't yet determined *why* this is happening, but
we can tell you *what* is happening.

When the SAMBA server comes on line, it does not appear in the WINS
database, but it *does* appear in Server Manager, and reports itself as
a Windows NT 4.2 Server.  After some period of time (which appears to be
random, but less than 24 hours) it begins to report itself as a BDC
(Windows NT 4.2 Backup.)

At that point, if the PDC is taken down for any reason, it cannot be
brought up again.  When rebooting the PDC it will report there is
already a PDC in the domain and refuse to complete the boot process, yet
Server Manager reports there is*no* PDC in the domain.  It is impossible to
"promote" or "demote" the PDC or to bring it back on line any other way.
At this point, domain logons will begin failing, and the domain essentially
becomes unusable.  The only solution is to kill the SAMBA server, at which
point the PDC will finish booting and the domain will return to normal.

The SAMBA team claims to have avoided this problem in 2.0 according to
Jeremy Allison:

        "This very problem is why my new code in 2.0 explicitly forces
the Samba admin to give the name or IP address of the PDC to authenticate
to, and to allow the name resolution to be forced to
look only in the local hosts file on that machine."

However, we are presently experiencing this problem on our "real" domain
with what appears to be a SAMBA 2.0 server (At least it reports itself as
that in Server Manager.)  I say "appears to be", because we just found the
suspect server today, and I can't confirm all the details of its
configuration at this time.  It definitely disrupted domain logons and
prevented the PDC from rebooting.  (We had one processor suffering from
heat related failure and had to shut down the PDC last Friday to replace a
defective fan.)

Microsoft's Security Response team has looked at this issue and
determined that it cannot be addressed in NT 4.0 due to the insecure nature
of WINS and NTLM.  They claim it will be fixed in Windows 2000:

        "In Windows 2000, DC are located using DNS lookups with
authenticated DNS updates of service location information, so we believe
that homogeneous Windows 2000 networks will not be susceptible to this
problem."

Security:
**************
We all know Windows 95/98 is inherently insecure.  With a SAMBA server
configured as above, it is possible to effect logons on the SAMBA
server.  During our troubleshooting, we noticed that machines all over
campus were being logged on by the SAMBA server, which would query a "real"
DC for the auth and then pass the auth to the client.  This opens an
obvious avenue of attack.

We copied the files from the NETLOGON share on a BDC to the newly
created NETLOGON share on the SAMBA server.  We then wrote a program
spoofing the Windows Logon screen, popped up an error message that
essentially said "your logon had failed, please reenter your
username/password" and were able to get users to enter their
username/password combo into our program, which wrote them to a text file
on the SAMBA server.  (NT Workstations are unaffected by the SAMBA logon
since they won't authenticate without an exchange of tokens.)

The workaround for this security hole, according to Microsoft is:

"1. Locating Valid Logon DCs:

                The workaround here is to use LMHOSTS to point clients
to logon DCs.  There are two Knowledge Base articles, at
http://support.microsoft.com/support/kb/articles/q192/0/64.asp and
http://support.microsoft.com/support/kb/articles/q150/8/00.asp, that
provide info on how to do this.  This is not a complete fix, because the
attacker can still spoof the servers at the IP layer (respond to ARP for
the servers' IP addresses). However, it does mean that any spoofing that is
done must be done at the IP layer, which is harder.

2. Locating Valid Logon Script Shares:

                With Windows NT 4.0 SP3 and Win9x, it is possible to
configure clients to require SMB packet signing.  Once this is done,
only members of some trusted domain can spoof the NETLOGON shares. It also
means that clients will refuse to access shares on servers that don't
support SMB signing, which is any server earlier than NT4/SP3: Win9x
servers or NT3.x servers or Samba servers, for example.  Alternatively, you
could configure LMHOSTS entries on clients for servers that provide logon
script shares.  This is a less effective workaround than SMB signing, but
would allow clients to use downlevel SMB servers."

Our testing has confirmed that this workaround will prevent Win95/98
clients from logging in to the domain through a SAMBA server.

We are still in contact with Microsoft on these issues, and if anything
of note transpires we will notify the list again.