COMMAND
Samba
SYSTEMS AFFECTED
Win 9x, NT
PROBLEM
Paul L. Schmehl posted following. The first is a DoS issue and
the second is a logon security issue. Here's 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. It wasn'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. Even this
"has been fixed" in SAMBA 2.0 server, test team is presently
experiencing this problem on their "real" domain with what appears
to be a SAMBA 2.0 server (At least it reports itself as that in
Server Manager.) It definitely disrupted domain logons and
prevented the PDC from rebooting.
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 troubleshooting, test team 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. Test team
copied the files from the NETLOGON share on a BDC to the newly
created NETLOGON share on the SAMBA server. They 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 their 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.)
At the end, dpn't blame SAMBA. This is obviously a flaw in the
fundamental design of domain security, and Microsoft has
acknowledged that. The only point of SAMBA being involved is it
makes the task much easier because there's no authentication and
token exchange required!!!
SOLUTION
As for DoS, 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. 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 MS believe that homogeneous Windows 2000 networks
will not be susceptible to this problem).
The moral is to not enable domain logons if you have an existing
DC. You don't try to run to PDC's concurrently. Of course. The
problem is SAMBA doesn't exchange tokens with the other DCs before
becoming a member of the Domain Server Group. This isn't SAMBA's
fault, it's Microsoft's, for not having a secure method to
register DCs. Also, domain logons=yes is the default setting in
the smb.conf file, so this can be done completely without the
knowledge of the individual setting up SAMBA. This is apparently
still true in SAMBA 2.0.
The workaround for second issue, 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
http://support.microsoft.com/support/kb/articles/q150/8/00.asp
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.