Puzzled with NTLM dissector for wireshark

[Matthieu Patou]

Hi metze,

> Hi Matthieu,
>
> I don't no much details of the NTLM dissector, but I think it would be
> very cool if it would use the arcfour key of the keytab the krb5
> dissector also uses. And try them all, we already have code which can
> generate a keytab with all krb5 keys of a whole domain.
I am  very interested about  for another problem I have with a 
workstation  (so I do not have an easy access to its keytab).
The short story is that I have every days that sames errors message when 
my user start his computer:

Error at 20090319 100206
AutoEnrollment 15
Automatic certificate enrollment for local system failed to contact the active directory (0x8007054b).  The specified domain either does not exist or could not be contacted.
   Enrollment will not be performed.
  === Start ===
Error at 20090319 181659
NETLOGON 5719
No Domain Controller is available for domain SAMBA4 due to the following:
There are currently no logon servers available to service the logon request.
.

Make sure that the computer is connected to the network and try
again. If the problem persists, please contact your domain administrator.


>   And it would be
> nice if wireshark could decrypt NTLM and krb5 traffic with this information.
>
>    
Are you sure that the rc4 key contained in the keytab is the same that 
is used by the NTLM encoding ?
If so then for the case of a extended security exchange it's rather 
simple for me to include it.

Matthieu.
> metze
>    
>> I've been working last month on NTLM dissector and have been successful
>> using the documentation of
>> [MS-NLMP].pdf and the existing code.
>> I needed this because if kerberos is not available (ie. ports blocked on
>> the firewall) then AD or samba4 fall back on NTLM as an authentification
>> methods (for LDAP at least).
>> So my code works in the case of NTLMv1 but using NTLMv2 security
>> (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag), which was not covered
>> by the dissector. As this kind of authentification is also used in
>> Microsoft SPA mode in Outlook I definitly think it's worth including it
>> wireshark so I'm trying to integrate my stuff in the existing.
>>
>> But I'm lost at several points.
>>
>> First the create_ntlmssp_v1_key function contains this code:
>>
>> crypt_des_ecb(lm_password_hash, lmhash_key, lm_password_upper, 1);
>> crypt_des_ecb(lm_password_hash+8, lmhash_key, lm_password_upper+7, 1);
>> ntlmssp_generate_challenge_response(lm_challenge_response,
>>                lm_password_hash, serverchallenge);
>>
>>   /* Generate the LanMan Challenge Response */
>>
>>   /* Generate the NTLMSSP-v1 RC4 Key.
>>     * The RC4 key is derived from the Lan Manager Hash.
>>     * See lkcl "DCE/RPC over SMB" page 254 for the algorithm.
>>     */
>>     memset(pw21, 0xBD, sizeof(pw21));
>>     memcpy(pw21, lm_password_hash, sizeof(lm_password_hash));
>>
>>
>> But when I read the spec from Microsoft and the code of samba (
>> SMBsesskeygen_lm_sess_key of "source4/libcli/auth/smbencrypt.c" )
>> I understand that only the first 8 bytes of the lm_password_hash are
>> used and the rest is filled with 0xBD.
>>
>> So basically I've the impression that password decode of the NTLM decode
>> should never work and therefor I should replace it with something more
>> likely to work. But at the other hand it seems to me so strange that
>> someone commited something that obviously can't work. Did I miss
>> something ?
>>
>>
>> Then there is information from the NLMP documentation that seems partial
>> and sometimes wrong (how can someone who wrote the programs not being
>> able to document correctly ?).
>>
>> My main concern is how to generate the base key for the RC4 encryption
>> in case of session key based on LM hash and LM response.
>>
>>
>> In 3.4.5.1 it's stated that it's the session key that is used as a key
>> for the DES encryption (and LM_reponse as data) when the flag
>> NEGOTIATE_LM_KEY is activated
>> It's fairly similar to this following code of
>> source4/auth/ntlmssp/ntlmssp_client.c
>>        SMBsesskeygen_lm_sess_key(lm_session_key.data, lm_response.data,
>>                new_session_key.data);
>>
>> If I make the the assumption that the session key in this case is the lm
>> hash which is written nowhere that's pretty much sensible
>>
>> But in the NON_NT_SESSION_KEY and no NEGOTIATE_LM_KEY it's stated that
>> the session key should be a concat of first eight bytes of lm_hash and 8
>> null bytes.
>>
>> And in samba code I guess the code associated with this case (because
>> it's not explicitly tested against this flag)
>> is the following:
>>        static const uint8_t zeros[24];
>>        SMBsesskeygen_lm_sess_key(lm_session_key.data, zeros,
>>                new_session_key.data);
>>
>> Which basically do a DES with lm_session_key (that is lm_hash) as a key
>> and zeros as data and is quite different from NLMP proposal.
>>
>> To sum up, I'm a bit lost because I can't be sure that the MS spec is
>> good, nor samba3/4 implementation and I have the strange feeling that
>> wireshark dissector isn't dissecting much.
>>
>> Can some one light my way ?
>>
>> Matthieu.
>>
>>      
>
>