none
[MS-NLMP] Setting 'Network security: LAN Manager authentication level' to 0 in Windows 8 and Windows 10 result in signatures that mismatch the specifications RRS feed

  • Question

  • Hi,

    During many tests of an SMB2 server implementation, I have noticed a (single) case where the MIC signature of an NTLM authentication exchange differs from what the MS-NLMP specifications suggests.

    I'm sending a packet capture session to dochelp at microsoft.com.

    I'm able to repeatedly recreate this issue using the following configuration:

    1. Freshly installed Windows 8.1 or Windows 10 v1607.

    2. 'Network security: LAN Manager authentication level' is set to 'Send LM & NTLM responses' (a.k.a. registry security level 0)

    3. The client connects to an SMB server implementation that does not support NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY. instead, NTLMSSP_NEGOTIATE_LM_KEY is used.

    My tests suggests that when the client is Windows 7 SP1 (under the same conditions), the MIC signature is as expected,

    only when using Windows 8 / Windows 10, the issue occurs (MIC signature NOT as expected).

    In the packet capture you should observe the following:

    1. The User name is 'User' and the password is 'Password', the AUTHENTICATE_MESSAGE's NTChallengeResponse field is as expected.

    2. NTLMSSP_NEGOTIATE_KEY_EXCH is set (p.s. the issue can be recreated even if the server does not set NTLMSSP_NEGOTIATE_KEY_EXCH).

    3. ServerChallenge: '29 CD 3C 9A 85 70 41 4C'.

    4. EncryptedRandonSessionKey: '88 9B 6E B4 59 27 78 A9 24 B2 76 80 48 81 FF E4'.

    5. NTOWF('Password'): 'A4 F4 9C 40 65 10 BD CA B6 82 4E E7 C3 F D8 52'.

    6. LMOWF('Password'): 'E5 2C AC 67 41 9A 9A 22 4A 3B 10 8F 3F A6 CB 6D'.

    7. Per 3.3.1, I'm expecting SessionBaseKey to be MD4(NTOWF('Password')): 'D8 72 62 B0 CD E4 B1 CB 74 99 BE CC CD F1 7 84'.

    8. Per 3.4.5.1, I'm expecting KeyExchangeKey to be '1C FB AD 6A 7B C6 66 5D A1 F2 97 5D DE 70 E2 D1'.

    9. Per 3.2.5.1.2, I'm expecting ExportedSessionKey to be RC4(KeyExchangeKey, EncryptedRandonSessionKey):  '8D 2 21 E3 22 DC 31 3F 31 18 74 5C 2 DC 40 8D'.

    10.Per 3.2.5.1.2, I'm calculating the MIC of the negotiate, challenge and authenticate message,

    I'm getting 'E2 6 63 1E C5 A3 D DB AE 66 A1 6D D4 E1 C2 5C',

    The client sent: '93 52 EF 33 7F 11 4D 4B DB 70 EC D6 2C 4 70 1E', NOT AS EXPECTED.

    Thanks!

    Tal

    Thursday, March 2, 2017 6:50 PM

Answers

  • After an additional review I came to the realization that the Windows client is using 16 null bytes as LMOWF. perhaps this should be documented?

    p.s. The Windows 7 client that was "issue free" had 'Network security: Do not store LAN Manager hash value on next password change' set to 'Disabled.'

    • Edited by Tal Aloni Thursday, March 2, 2017 9:33 PM
    • Marked as answer by Tal Aloni Thursday, March 2, 2017 9:33 PM
    Thursday, March 2, 2017 9:28 PM

All replies

  • BLOBs:

    Type 1:

    '4E 54 4C 4D 53 53 50 00 01 00 00 00 97 82 08 E2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 03 80 25 00 00 00 0F'

    Type 2:

    '4E 54 4C 4D 53 53 50 00 02 00 00 00 06 00 06 00 38 00 00 00 95 02 82 E2 29 CD 3C 9A 85 70 41 4C 00 00 00 00 00 00 00 00 18 00 18 00 3E 00 00 00 05 02 CE 0E 00 00 00 0F 54 00 41 00 4C 00 02 00 06 00 54 00 41 00 4C 00 01 00 06 00 54 00 41 00 4C 00 00 00 00 00'

    Type 3:

    '4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 80 00 00 00 18 00 18 00 98 00 00 00 10 00 10 00 58 00 00 00 08 00 08 00 68 00 00 00 10 00 10 00 70 00 00 00 10 00 10 00 B0 00 00 00 95 02 80 E2 06 03 80 25 00 00 00 0F 93 52 EF 33 7F 11 4D 4B DB 70 EC D6 2C 04 70 1E 54 00 61 00 6C 00 2D 00 56 00 4D 00 31 00 31 00 55 00 73 00 65 00 72 00 54 00 41 00 4C 00 2D 00 56 00 4D 00 31 00 31 00 5F 1E 6D 54 FE 53 4E BB B2 A6 47 4D E3 43 AB 3E A7 F1 FB E9 44 CC D0 7E 5F 1E 6D 54 FE 53 4E BB B2 A6 47 4D E3 43 AB 3E A7 F1 FB E9 44 CC D0 7E 88 9B 6E B4 59 27 78 A9 24 B2 76 80 48 81 FF E4'

    MIC is calculated on this buffer (type1 + type2 + type3, the MIC sent by the client is zeroed out):

    '4E 54 4C 4D 53 53 50 00 01 00 00 00 97 82 08 E2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 03 80 25 00 00 00 0F 4E 54 4C 4D 53 53 50 00 02 00 00 00 06 00 06 00 38 00 00 00 95 02 82 E2 29 CD 3C 9A 85 70 41 4C 00 00 00 00 00 00 00 00 18 00 18 00 3E 00 00 00 05 02 CE 0E 00 00 00 0F 54 00 41 00 4C 00 02 00 06 00 54 00 41 00 4C 00 01 00 06 00 54 00 41 00 4C 00 00 00 00 00 4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 80 00 00 00 18 00 18 00 98 00 00 00 10 00 10 00 58 00 00 00 08 00 08 00 68 00 00 00 10 00 10 00 70 00 00 00 10 00 10 00 B0 00 00 00 95 02 80 E2 06 03 80 25 00 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 54 00 61 00 6C 00 2D 00 56 00 4D 00 31 00 31 00 55 00 73 00 65 00 72 00 54 00 41 00 4C 00 2D 00 56 00 4D 00 31 00 31 00 5F 1E 6D 54 FE 53 4E BB B2 A6 47 4D E3 43 AB 3E A7 F1 FB E9 44 CC D0 7E 5F 1E 6D 54 FE 53 4E BB B2 A6 47 4D E3 43 AB 3E A7 F1 FB E9 44 CC D0 7E 88 9B 6E B4 59 27 78 A9 24 B2 76 80 48 81 FF E4'

    Thursday, March 2, 2017 6:56 PM
  • Hi Tal,

    Thanks for raising your question on MS-NLMP. I also noticed your packet traces that you sent to the DOCHELP alias. I have created a Service Request, SR# 117030215399307, to track your issue and will include the packet traces you send via email. An engineer on the Open Specification team will be touching base with you regarding your issue.

    Sincerely,

    Will Gregg | escalation engineer | open specifications

    Thursday, March 2, 2017 7:06 PM
    Moderator
  • After an additional review I came to the realization that the Windows client is using 16 null bytes as LMOWF. perhaps this should be documented?

    p.s. The Windows 7 client that was "issue free" had 'Network security: Do not store LAN Manager hash value on next password change' set to 'Disabled.'

    • Edited by Tal Aloni Thursday, March 2, 2017 9:33 PM
    • Marked as answer by Tal Aloni Thursday, March 2, 2017 9:33 PM
    Thursday, March 2, 2017 9:28 PM
  • UPDATE: 3/6/2017

    Tal Aloni was able to resolve his question. Open specifications team is working on verifying MS-NLMP updates.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Monday, March 6, 2017 6:41 PM
    Moderator