Date: Tue, 2 Mar 1999 16:43:10 -0600 From: Paul L Schmehl To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: NT Domain DoS and Security Exploit with SAMBA Server 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. -------------------------------------------------------------------------------- Date: Tue, 2 Mar 1999 22:42:15 -0600 From: Gerald Carter Reply-To: jerry@Eng.Auburn.EDU To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Domain DoS and Security Exploit with SAMBA Server Paul L Schmehl wrote: > > security=server > password server=[hostname of PDC] > domain controller=[hostname of PDC] This is a boolean parameter in the current code (and obselete I might add) > 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 If you set the workgroup to be the same as the domain of the NT PDC you are referring to, Samba will attempt to register the workgroup<1b> record (due to domain logons being enabled). Windows clients use this to locate the DC for their workgroup > 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.) The annouce as in Samba 2.0.3 allows you to advertise as a workstation although the default is still to advertise as a Server. The moral is to not enable domain logons if you have an existing DC. You don't try to run to PDC's concurrently. Same here > 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. correct. The problem is the dynamic nature in which NetBIOS names are registered and released. It is insecure. > 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. Don't get this. So you wrote a mimic program. Not sure how this relates. Could do this without Samba. Again, just to clarify, * why are you trying to bring up to DC's (Samba and NT)? * Assuming that you a meaning that anyone on the network can do this, I agree it can disrupt service, but is not specific to Samba. Imagine this scenario, - I install a Windows NT Server as a PDC off the network in your domain. - Then I connect it to the network. - it will also attempt to take over, right? What's the difference? The problem appears to be netbios name resolutions and regostration and not Samba. Aplogies if I misunderstood you post. Comments and corrections always welcome. jerry carter ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) -------------------------------------------------------------------------------- Date: Wed, 3 Mar 1999 10:18:08 -0600 From: Paul L Schmehl To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Domain DoS and Security Exploit with SAMBA Server Comments below. --On Tuesday, March 02, 1999, 10:42 PM -0600 Gerald Carter wrote: [snip] > > The moral is to not enable domain logons if you have an > existing DC. You don't try to run to PDC's concurrently. > Same here 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, because the server I mentioned in my post took down the domain without the knowledge of the admin who set it up. > [snip] > > Don't get this. So you wrote a mimic program. Not sure how > this relates. Could do this without Samba. How? You have to have something which is seen by clients as a DC with a NETLOGON share before you can start processing logons. You can't do that with an NT server without knowing the domain administrator password. You can do it with SAMBA without any authentication at all. > > Again, just to clarify, > > * why are you trying to bring up to DC's (Samba and NT)? We're not. They do that be default. And that's my point. *Anyone* in your organization can bring up a SAMBA server and take down the domain (under the right circumstances as posted.) This has already happened to us twice, both times without the knowledge or approval of the IR department. [snip] > > What's the difference? The problem appears to be > netbios name resolutions and regostration and not > Samba. Aplogies if I misunderstood you post. I'm not blaming 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. > > > > > Comments and corrections always welcome. > jerry carter > ________________________________________________________________________ > Gerald ( Jerry ) Carter > Engineering Network Services Auburn University > jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw > > "...a hundred billion castaways looking for a home." > - Sting "Message in a Bottle" ( 1979 )