samba - Nov 1997 - [NTSEC] NTDOM: negotiating either RC4 _or_ some other crypt m echanism

On Sun, 2 Nov 1997, Russ wrote:
> >if it's correct, then the implications are that if you can sniff an
> entire
> >packet trace of a domain setup / logon / logoff, then you can decrypt
> the
> >long-term session key.
> 
> 1. If the machine is not added to a domain, does the machine password
> stay the same (or even get created)?
i don't think so.  i _think_ it is created on-demand, when the
LSA_OPENPOLICY occurs (the request contains the workstation's name).  if
so, i have a bug in my current implementation.

[successful policy opening results in the message "welcome to the
..."]

otherwise, when you do a login, and WINLOGON.EXE initiates a connection, 
you wouldn't have a username (MACHINE$) / password (LM hash of unicode 
string "machine") with which to connect to the PDC.
> If not, then the exploit might be
> thwarted by doing the install against a disconnected hub, then adding
> the machine to the domain after setup is complete (since the machine
> password might not be predictable at that point).
if the workstation is disconnected, you can't ever join a domain.  unless 
you isolate the workstation and the server temporarily from everything 
else, and get one user to log in once.

the machine password stays at the default value until the first time the
first user logs in.  this will get the workstation to do a
"NetrServerPasswordSet" with a random workstation password. 
[encrypted
with rc4 or the other mechanism, using the long-term session key which was
generated from the default machine password... *sigh*]. 

> 2. What happens when a machine is moved into a domain. My understanding
> is that a machine password is negotiated at this point also.
"moved" into a domain, and "added" to a domain are the same
thing, to the
best of my knowledge.  if you mean something different, please let me know.

(in other words, you can only remove a machine from a domain, and then 
only add it to one).
> So setting
> the machine up in a Setup domain first, then putting it in place and
> adding it to the destination domain may also thwart this risk. Of course
> its also possible that the session key used when changing domains has
> nothing to do with the past machine password, but instead defaults to
> the LM hash of the lower-case Unicode version of the machine name (which
> means its also possible to perform your magic when machines move
> domains, not just when their initially set up).
now i'm lost.  sorry.

> 3. Where did the LM 16 byte hash of the Unicode lower-case machine name
> come from, I don't remember seeing that published anywhere.
there will probably be a KB article published on it in the next few weeks
that's been available for years. 

luke



<a href="mailto:lkcl@switchboard.net"  > Luke Kenneth Casson
Leighton </a>
<a href="http://mailhost.cb1.com/~lkcl"> Lynx2.7-friendly Home
Page   </a>
<br><b> "Apply the Laws of Nature to your environment because
your
         environment applies the Laws of Nature to you"              
</b>

On Sun, 2 Nov 1997, Russ wrote:
> >if it's correct, then the implications are that if you can sniff an
> entire
> >packet trace of a domain setup / logon / logoff, then you can decrypt
> the
> >long-term session key.
> 
> 1. If the machine is not added to a domain, does the machine password
> stay the same (or even get created)? If not, then the exploit might be
> thwarted by doing the install against a disconnected hub, then adding
> the machine to the domain after setup is complete (since the machine
> password might not be predictable at that point).
ok,

in my first reply to this, i mentioned that it might be the case that 
during the "Welcome to the ..... Domain" setup, the workstation
account
is created (with the initial password).

unless the workstation name is deduced from the NetBIOS session 
connection and this is used, i don't believe this to be the case (again, 
this is all speculation).

i have seen SMB sessions refused with a specific error message (something 
like "no NT LOGON account" during the ctrl-alt-delete stage when a
user
first logs in to a domain.

also, part of the "Welcome to the .... Domain" setup requires that you
return a specific error code to an SMB session setup:

	(NT_STATUS_ALLOTTED_SPACE_EXCEEDED - 0xC000 0099...)

if you do not do this, you will get "error: you are already a member of 
the domain.  please unjoin domain first".  or some-such.


this has me a bit stumped: when exactly do you create the WORKSTATION$
account with the initial default password of workstation?  does it matter?


[all this, and more, will probably never be answered, in next week's
 exciting installment...]


luke


<a href="mailto:lkcl@switchboard.net"  > Luke Kenneth Casson
Leighton </a>
<a href="http://mailhost.cb1.com/~lkcl"> Lynx2.7-friendly Home
Page   </a>
<br><b> "Apply the Laws of Nature to your environment because
your
         environment applies the Laws of Nature to you"              
</b>