[NTSEC] NTDOM: negotiating either RC4 _or_ some other crypt m echanism

[Luke Kenneth Casson Leighton]

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 at 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>