MIC check always fails on accept context

[SergeyPachkov]

gss-ntlmssp/src/gss_sec_ctx.c

Line 972 in a2517e5

retmin = ntlm_verify_mic(&ctx->exported_session_key,

I wrote small server on Linux (DCE/RPC server with NTLM authentication) using gssapi and ntlmssp (1.1.0) mech to handle client connections from Windows 10.

on connect a new client everything looks ok except MIC verification. in debugger I see all headers were parsed in right way (wireshark exposes all headers exactly the same), also winbind returned with OK for user
but computed MIC doesn't match to provided with packet from Windows

I think issue has root in what source of data is used in computation (length, incorrect start position or something like that)
because algorithms code looks good from first view.

I glad to hear any help or idea for research .

[simo5]

So this is a windows client failing mic verification?
Or is this your server failing to verify the MIC sent by the client?

[SergeyPachkov]

Server calls second time accept context on auth leg, and fails on first mic check 1: client sends negotitate 2: server sends challenge 3: client sends authenticate Server code iteracts with winbind in gssntlm_accept_context and fails on mic verification. ср, 8 февр. 2023 г., 00:31 Simo Sorce ***@***.***>:

…

So this is a windows client failing mic verification? Or is this your server failing to verify the MIC sent by the client? — Reply to this email directly, view it on GitHub <#86 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP3CSEX4EIZRNUIHCHULIY3WWK5KHANCNFSM6AAAAAAUUOBGA4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SergeyPachkov]

In debuging of gssntlmssp & network data I see following:

Windows client : pkt privacy
NTLMSSP_NEGOTIATE, flags: 0xe20882b7( Negotiate 56, Negotiate Key Exchange, Negotiate 128, Negotiate Version, Negotiate Extended Security, Negotiate Always Sign, Negotiate NTLM key, Negotiate Lan Manager Key, Negotiate Seal, Negotiate Sign, Request Target, Negoteate OEM, Negotiate Unicode)

Server on Linux (gssntlmssp) replys:
NTLMSSP_CHALLENGE: flags 0xe2898235
challenge: d295c07ad1267312

Client has sent 'auth' and Server handles it with:

key_exchange_key from gssntlm_srv_auth: de ae 3b 3c 49 c2 4b 75 5e 97 e3 b5 b8 9c fd 6f
enc_sess_key: 8a ca 9f 81 89 96 39 c8 8c b9 c9 35 86 8c 25 8e

after ntlm_encrypted_session_key at line 950:
exported_session_key: 91 af 8e 54 5d ff d3 a6 d3 ec 3e 65 10 ca 7a 6b

and then gssntlmssp calls ntlm_verify_mic at gss_sec_ctx.c:963

            retmin = ntlm_verify_mic(&ctx->exported_session_key,
                                     &ctx->nego_msg, &ctx->chal_msg,
                                     &ctx->auth_msg, &mic);

nego_msg, 40:
4e 54 4c 4d 53 53 50 00 01 00 00 00 b7 82 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 61 4a 00 00 00 0f

chal_msg, 148:
4e 54 4c 4d 53 53 50 00 02 00 00 00 08 00 08 00 38 00 00 00 35 82 89 e2 d2 95 c0 7a d1 26 73 12 00 00 00 00 00 00 00 00 54 00 54 00 40 00 00 00 06 02 00 00 00 00 00 0f 54 00 45 00 53 00 54 00 01 00 0a 00 41 00 4c 00 54 00 30 00 31 00 02 00 08 00 54 00 45 00 53 00 54 00 03 00 1e 00 61 00 6c 00 74 00 30 00 31 00 2e 00 74 00 65 00 73 00 74 00 2e 00 61 00 64 00 6c 00 70 00 06 00 04 00 00 00 00 00 07 00 08 00 d6 94 1f 91 96 3b d9 01 00 00 00 00

auth_msg, 400:
4e 54 4c 4d 53 53 50 00 03 00 00 00 18 00 18 00 98 00 00 00 d0 00 d0 00 b0 00 00 00 12 00 12 00 58 00 00 00 10 00 10 00 6a 00 00 00 1e 00 1e 00 7a 00 00 00 10 00 10 00 80 01 00 00 35 82 88 e2 0a 00 61 4a 00 00 00 0f fa c6 22 54 45 1a a8 31 d2 af f5 4f 21 21 9e 2e 54 00 45 00 53 00 54 00 2e 00 41 00 44 00 4c 00 50 00 74 00 65 00 73 00 74 00 75 00 73 00 65 00 72 00 53 00 45 00 52 00 47 00 45 00 59 00 50 00 41 00 43 00 48 00 4b 00 30 00 32 00 30 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 ef d5 ef a2 25 81 f2 09 9a 78 db 3c 30 03 24 01 01 00 00 00 00 00 00 d6 94 1f 91 96 3b d9 01 2b 98 70 d5 08 5a e5 8a 00 00 00 00 01 00 0a 00 41 00 4c 00 54 00 30 00 31 00 02 00 08 00 54 00 45 00 53 00 54 00 03 00 1e 00 61 00 6c 00 74 00 30 00 31 00 2e 00 74 00 65 00 73 00 74 00 2e 00 61 00 64 00 6c 00 70 00 06 00 04 00 06 00 00 00 07 00 08 00 d6 94 1f 91 96 3b d9 01 08 00 30 00 30 00 00 00 00 00 00 00 01 00 00 00 00 20 00 00 e1 ba 94 58 31 aa b4 53 b7 c7 8a 7a ba 60 3c d2 93 fc d3 31 6f 53 bb 4a 27 df da b1 9c c1 60 32 0a 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 8a ca 9f 81 89 96 39 c8 8c b9 c9 35 86 8c 25 8e

ntlm_mic at ntlm_crypto.c: 996
returns check_mic, 16: 3d de 9c 2e d4 30 7d 86 8d b1 af d5 e6 ba 54 94
and fails on cmp with mic from Windows client: fa c6 22 54 45 1a a8 31 d2 af f5 4f 21 21 9e 2e
mic-fail-mic-rpc.pcapng.zip

[SergeyPachkov]

Simple test with data collected from debugging and network

check_mic.zip

[simo5]

I assume you are using Winbind integration because you are trying to interoperate in a Windows domain.
Have you checked if this works in a standalone situation?

The interface between Winbindd and gss-ntlmssp is good but not perfect, because winbindd makes some assumptions I cannot always influence through the available interface (I knew a lot more when I wrote that code, but forgot a bit since then). And I know there are some situations where MIC can indeed fail. So it would be good to first rule out general issues by simplifying the problem by removing winbindd from the picture, and adding it back is we are sure it works otherwise.

[SergeyPachkov]

yes, winbindd.
ENV: DC-Windows2019, Linux (Server/DCERPC) as domain member, Windows10 : non-domain, standalone client

gssntlm_acquire_cred_from usually fails on call winbind_get_creds/ wbcCtxCredentialCache(ctx, &params, &result, NULL) returns DOMAIN_NOT_FOUND

and gssntlmssp goes into winbind_srv_auth that returns OK

    wbc_status = wbcCtxAuthenticateUserEx(ctx, &wbc_params, &wbc_info,
                                          &wbc_err);
.....

    memcpy(ntlmv2_key->data, wbc_info->user_session_key, ntlmv2_key->length);

then ntlmv2_key is used as source for key_exchange_key value

ok, i will try it out with NTLM_USER_FILE

[simo5]

Thanks,
note that some protocols had to apply quirks to MIC calculation, for example if it is done withing SPNEGO, but it doesn't seem the case here. This looks like regular DCE-RPC over TCP/IP which should be the simplest to handle. Unless you are required to use Channel-Bindings withing a TLS connection (I did not see CBs in the Target_Info so doesn't look like this is the case).

[SergeyPachkov]

@simo5 I think it is first exp to use dcerpc on linux with gssntlmssp mech:

according to source code: https://github.com/dcerpc/dcerpc/blob/master/dcerpc/ncklib/gssauthcn.c#L2098
dcerpc requires support of 3 additional calls: gss_wrap_iov / gss_unwrap_iov / gss_wrap_iov_length

I think it is first time to use dcerpc with gssapi + ntlmssp auth on Linux;

returning to NTLM_USER_FILE. I added user into file, checked in debugger how gssntlm_accept_sec_context handled it
no luck - mic check failed
then I commented out mic check to go through
and replaced gss_unwrap_iov with my code to decrypt next network packet: but signature check failed,
I dont understand was it decrypted in right way or not ?

just for compare: Apple's code to accept ntlm context
https://github.com/apple-oss-distributions/Heimdal/blob/602e684b8d9f1924c6ccf561ea6cee792fd30cb5/lib/gssapi/ntlm/accept_sec_context.c#L440

they do a little different operations on session_key

[simo5]

As far as I can tell their code is functionally equivalent to ntlm_mic() which is what is called to verify the mic in gssntlmssp.

I do not think it is a code problem, it may be a key derivation issue, or some other quirk of the crypto state.

In spnego for example when MIC is calculated, MS implementation then resets the internal crypto status to the point before the MIC was calculated.
You can see how we implemented this quirk in gssapi here:
https://github.com/krb5/krb5/blob/6ecf843bf1e8653c988d2eddba56613f79abe05c/src/lib/gssapi/spnego/spnego_mech.c#L527

I am not saying this particular quirk affects you, only that, unfortunately using a MIC with NTLSSP is not straightforward and sometimes under or poorly documented.

Does your code work if you change negotiation flags to void using a MIC? (trying go figure out if we actually ave a simple option to force that, if not that could be a useful debug tunable and may be worth trying to add it).

[SergeyPachkov]

@simo5 issue was related to 'timestamp' param in BIND-ACK

I removed it to send from server-side, and then Win-client 'disabled' MIC presence but Win-client added it to AUTH3 anyway (yes, even MIC-flag is off)
in this case MIC is valid and everything go in right way.

[simo5]

This is really interesting.
It means when we set timestamp we are not calculating the MIC as expected.
I will try to recheck the MS NLMP docs again to see if I missed anything.
If you spot something in there let me know.

[SergeyPachkov]

I dont think code is wrong, may be spec from msft is not complete. чт, 9 мар. 2023 г., 17:32 Simo Sorce ***@***.***>:

…

This is really interesting. It means when we set timestamp we are not calculating the MIC as expected. I will try to recheck the MS NLMP <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/> docs again to see if I missed anything. If you spot something in there let me know. — Reply to this email directly, view it on GitHub <#86 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP3CSEWL7OD62K4UO2O4HKLW3HLVXANCNFSM6AAAAAAUUOBGA4> . You are receiving this because you authored the thread.Message ID: ***@***.***>