To update: I was able to finally track the code down for session key generation to auth/ntlmssp/ntlmssp_client.c - cli_credentials_get_ntlm_response function and realized that the signing key was in fact the random session key I was generating as part of NTLMv2 with key exchange.
Given that I am able to sign messages now, it also appears the the key in fact does change between SMB2 sessions wheras SMB1 does not. I guess that I've answered my own questions. So unless something I've said is incorrect, thanks everyone for your time! B On Wed, Feb 20, 2013 at 4:09 PM, Brad Fewster <[email protected]>wrote: > Hi everyone, > > First off, I'm new to the list so excuse me if my mailing list etiquette > is not quite up to par. > > I have a few questions regarding SMB2 and signing that I'm hoping someone > here can help me with. Note that I'm only concerned with the client, not > the server, so all of my questions fall within the context of an SMB2 > client. > > Also I've done ALOT of reading of internet sources, Samba code, and MS > documentation which has left me in a thoroughly confused state as to which > methodologies apply to SMB, SMB2, NTLMv1, and NTLMv2. > > My apologies if this isn't the right place for NTLM questions, but I am > not sure where else to ask since this is apparently directly related to the > SMB2 signing key. > > > Question 1: Signing Key Format with NTLMv2 > > I'm looking at a connection in which the session setup is occurring (with > regard to packet layout) using NTLMv2 inside NTLMSSP inside SPNEGO inside > GSS-API. > > What I'd like to know is what exactly is used as the "session key" to sign > SMB2 packets? I am confused by the signing key information contained > within [MS-NLMP] with regard to signing and sealing keys, some resources > seem to indicate that that has no bearing on the SMB signing key, but I'm > not sure that applies to SMB and/or SMB2 as the lines seem to be a bit > blurred. > > The current routine I'm using to generate the key used to sign SMB2 > packets per [MS-SMB2] section 3.1.4.1 is: > username = ASCIIZ username (i.e. "brad") > domain = ASCIIZ target domain (typically the hostname from the > NTLMSSP_CHALLENGE, i.e. "WIN7-X64-01") > password = ASCIIZ password (i.e. "secret") > server_challenge = 8-byte challenge received from the server (from > NTLMSSP_CHALLENGE's NTLM Server Challenge field) > client_challenge = random 8-byte nonce (generated by me) > target_info = "target info" block from NTLMSSP_CHALLENGE from server > v1Hash = MD4(UNICODE_LE(password)) [ as per heim_ntlm_nt_key ] (16 > bytes) > v2Hash = HMAC_MD5(UNICODE_LE(username)+UNICODE_LE(domain)) using all > 16bytes of v1Hash as key > ntlmv2_response = all but the first 16 bytes of the response that I am > SENDING to the client > hmac = HMAC_MD5(ntlmv2_response) using all 16 bytes of v2Hash as the key > signingKey = HMAC_MD5(v2Hash) using all 16 bytes of 'hmac' as the > session key > > This isn't working for signing - my Windows 7 x64 Ultimate box rejects > packets signed using the above signingKey. Simply an ACCESS_DENIED error > is returned; if I disable signing then the commands work so it's not a > legitimate permissions problem. I've gone over the actual signing code > many times, which is simple compared to the NTLMv2 negotiation. I'm > confident the signing code is OK and the key above is incorrect. > > Authentication for NTLMv2 is woking correctly, so I also have access to > all of the various artifacts of that process. > > I think I've gotten lost somewhere in the mountain of hashes and different > signing keys. Does SMBv2 require some of the "magic signing keys" to be > used as documented in [MS-NLMP] to derive it's signing keys? Various > scraping of information on the interwebs leads me to believe 'no', but I > can't be 100% certain. > > Various other permutations have been tries using assorted keys from the > NTLMv2 process, the server and client challenge's, magic signing keys from > [MS-NLMP], etc to no avail. > > BTW, the flags I'm using in my NTLMSSP_NEGOTIATE are 0x60088215 and the > ones returned by the server are 0x628a8215. > > > > Question 2: Signing Key Retention > > Assuming that Q1 is answered and I'm able to obtain the proper signing key > for SMB2 packets, is the key used to set the 'signature' field in the SMB2 > header retained across SessionSetup/Logoff instances? > > This appears to be the case in SMB1 and looking at [MS-SMB2] in section > 3.2.5.3.2 it reads "The client MUST NOT regenerate Session.SessionKey.". I > read this to mean that SMB2 behaves like SMB1 in that if a session key is > established during the initial SessionSetup exchange that it will remain > unchanged even if a Logoff is processed followed by another SessionSetup. > > > > Thanks for anyone who can help, > B > >
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
