search

gssapi / gss-ntlmssp

A complete implementation of the MS-NLMP documents as a GSSAPI mechanism
ISC License
30 stars 26 forks source link

signature without integrity does not match SSPI #19

Closed jborean93 closed 4 years ago

jborean93 commented 4 years ago

When a security context does not having signing/integrity negotiated but NTLMSSP_NEGOTIATE_ALWAYS_SIGN is set SSPI will generate a signature of \x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00. This library generates a signature of \x00 * 16. I can't find this mentioned anywhere in MS-NLMP but the Davenport NTLM docs does mention this under "Dummy" Signing

This is used if the SSPI context was initialized without specifying support for message integrity. If the "Negotiate Always Sign" NTLM flag is established, calls to MakeSignature will succeed, returning the constant "signature":

0x01000000000000000000000000000000

Here are the various permutations I've tried:

Flags SSPI GSSAPI
0¹ N/A² N/A²
ALWAYS_SIGN 01000000000000000000000000000000 00000000000000000000000000000000
ALWAYS_SIGN, SIGN 010000007D9A8B2A8D70259900000000 01000000AE0D7D7DF4AF985800000000
ALWAYS_SIGN, SEAL N/A³ 00000000000000000000000000000000
ALWAYS_SIGN, SEAL, SIGN 0100000080363D8599F6A5D200000000 01000000B64F49F73A83493600000000

_¹ - 0 means neither ALWAYSSIGN, SIGN, or SEAL is set. _² - SSPI and GSSAPI always sets NTLMSSP_NEGOTIATE_ALWAYS_SIGN so I cannot test this there._ ³ - Setting SEAL will always set SIGN for SSPI.

Just as an FYI, the seq number part of the dummy signature does not increment when signing a 2nd message using SSPI.

simo5 commented 4 years ago

so this is with NTLMv2 ? And this indicates that in the dummy signature the sequence number is permanently returning 1 as the value ?

jborean93 commented 4 years ago

so this is with NTLMv2 ?

Yep, the NTLMSSP_NEGOTIATE_ALWAYS_SIGN flag indicates that signing is always available using this dummy signature if NTLMSSP_NEGOTIATE_SIGN or NTLMSSP_NEGOTIATE_SEAL isn't negotiated. In GSSAPI land this can occur if the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG are not set during the token exchange.

And this indicates that in the dummy signature the sequence number is permanently returning 1 as the value ?

The first 4 bytes for both NTLM and NTLM with ESS indicate the first 4 bytes are the signature version not the sequence number. When generating multiple signatures from the same context the actual SeqNum part never changes and the signature in this scenario is always 01000000000000000000000000000000 from SSPI.

simo5 commented 4 years ago

so this is with NTLMv2 ?

Yep, the NTLMSSP_NEGOTIATE_ALWAYS_SIGN flag indicates that signing is always available using this dummy signature if NTLMSSP_NEGOTIATE_SIGN or NTLMSSP_NEGOTIATE_SEAL isn't negotiated. In GSSAPI land this can occur if the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG are not set during the token exchange.

My question was more about: is this the same in NTLMv1 vs NTLMv2 ? The rest is already hanndled correctly here, ie returning all zeros is not an accident it's just the first byte is the sequence number and it is set to 0 as the starting point.

And this indicates that in the dummy signature the sequence number is permanently returning 1 as the value ?

The first 4 bytes for both NTLM and NTLM with ESS indicate the first 4 bytes are the signature version not the sequence number. When generating multiple signatures from the same context the actual SeqNum part never changes and the signature in this scenario is always 01000000000000000000000000000000 from SSPI.

So I have the signature version handled as well, but apparently not the same way in all cases.

Can you tell me how did you extract the signatures from gssapi ?

simo5 commented 4 years ago

Ok found the issue see #21 pls