NTDOM: negotiating either RC4 _or_ some other crypt mechanism

[Luke Kenneth Casson Leighton]

this relates to NT 4.0 and NT 3.5 Domain Authentication, for the LSA Net
Server Password Set mechanism.  the long-term session key is generated
from the machine password, which is used to communicate the new machine
password.

[when you join a domain, the initial machine password is the LM 16 byte
hash of the unicode name of the server, in lower-case.  one of the first
things that is attempted when you first log in to that domain, following
the obligatory reboot, is to randomly generate another machine password,
and communicate it to the server using LSA Net Server Password Set. 
described below is the reversible encryption mechanism that appears to be
used to do this...]


it would appear, from the pseudo-code, that it's possible to negotiate rc4
_or_ a two-des encrypt of the machine password and/or user password. the
16 byte long-term session key is used as the encryption key.  the 17th
byte is a "negotiate rc4" flag.

the exact mechanism for this negotiation is unknown, although the
implementation in rpc_pipes/ of samba-1.9.18alpha10 appears to negotiate
this correctly, because c:\winnt\debug\netlogon.log output shows
[EncryptRC4] and [DecryptRC4] messages at the appropriate points. 

if this negotiated flag is 4, then rc4 is used.  you take the 16 byte LM
OWF, and do a 16 byte rc4 encrypt using the long-term session key.  you
then take the 16 byte NT OWF, and do another 16 byte rc4 encrypt, using
the long-term session key.

if the negotiated flag is not 4, then you take the first 8 bytes of the
long-term session key, ignore the 8th byte and use this as a key to do a
DES_ECB_LM on the first 8 bytes of the 16 byte NT OWF.  then you take the
next 8 bytes of the long-term session key, ignore the last byte and use
this as a key to do a DEC_ECB_LM on the second 8 bytes of the 16 byte NT
OWF. the 16 byte LM OWF appears to be completely ignored in this.

i will write this up and implement it, and once verified, let you know. 
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.  if you know the long-term session key, then you
can follow the credential-generation, used in the LSA SAM Logon and LSA
Sam Logoff messages.  this may mean that, given that the reply to the LSA
SAM Logon contains user SAM information, that you can decrypt the user's
clear-text equivalent LM and NT 16 byte OWFs, but i have to double-check 
this.


you might not be able to do a man-in-the-middle attack (the validation 
chain system looks like a quite good one, to my non-security-background 
mind) but you can definitely "keep an eye on things".


credits to Paul Ashton <paul at argo.demon.co.uk> for his work on
understanding the NT Domain Authentication system (a copy is available at
http://mailhost.cb1.com/~lkcl/crypt.html): i missed out this stage.  this
is my first attempt at actually understanding and commenting on the
protocol itself :)

regards,

luke


references: http://mailhost.cb1.com/~lkcl/ntdomain.html

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