nt.domain.DoS.txt

`Date: Tue, 2 Mar 1999 16:43:10 -0600  
From: Paul L Schmehl <[email protected]>  
To: [email protected]  
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 <[email protected]>  
Reply-To: [email protected]  
To: [email protected]  
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  
[email protected] 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 <[email protected]>  
To: [email protected]  
Subject: Re: NT Domain DoS and Security Exploit with SAMBA Server  
  
Comments below.  
  
--On Tuesday, March 02, 1999, 10:42 PM -0600 Gerald Carter  
<[email protected]> 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  
> [email protected] http://www.eng.auburn.edu/users/cartegw  
>  
> "...a hundred billion castaways looking for a home."  
> - Sting "Message in a Bottle" ( 1979 )  
  
`