ntlmssp errors against El Capitan's SMB Server

[Simo]

On Tue, 2016-08-30 at 15:19 -0700, Jeremy Allison wrote:
> On Tue, Aug 30, 2016 at 04:40:54PM -0400, Simo wrote:
> > 
> > 
> > This is in 4178 5.b, this is not the case you are looking for, as
> > in
> > the NTLM case you exchange an odd number of tokens (Negotiate,
> > Challenge, Auth), while in the kerberos case you exchange an even
> > number of tokens (initiate token and accept token)
> > 
> > So you need to look at 4178 5.c 
> > in there you have things like:
> > 	if the
> >       negState was request-mic in the first reply from the target,
> > a
> >       mechlistMIC token MUST be included; otherwise, the
> > mechlistMIC
> >       token is OPTIONAL.
> > 
> > (in this pcacp the state was accept-incomplete)
> > 
> > Also:
> >       In the case that the optimistic mechanism token is the only
> >       mechanism token for the initiator's preferred mechanism, the
> >       mechlistMIC token is OPTIONAL.
> > 
> > (in this pcap NTLM was attempted optimistically and the initiator
> > did
> > not provide any other mechanism.
> > 
> > 
> > All this would still require the mechlistMIC to be produced from
> > the
> > server because the client did in fact send a mechlistMIC token
> > except
> > that in Appendix C we have:
> > 
> >    SPNEGO implementations in Microsoft Windows
> > 2000/Windows XP/Windows
> >    Server 2003 have the following behavior: no mechlistMIC is
> > produced
> >    and mechlistMIC is not processed if one is provided; if the
> > initiator
> >    sends the last mechanism token, the acceptor will send back a
> >    negotiation token with an accept_complete state and no
> > mechlistMIC
> >    token.  
> > 
> > I think this is the behavior we are seeing.
> 
> Ah, this is staring to make sense. In MS-NLMP we have:
> 
> If the CHALLENGE_MESSAGE TargetInfo field (section 2.2.1.2) has an
> MsvAvTimestamp present,
> the client SHOULD provide a MIC<51>:
> 
> So I'm guessing that in the latest version of the Apple
> server they added support for the MsvAvTimestamp in their
> NTLM implementation, but didn't add support for MIC processing
> in SPNEGO.
> 
> So they act like a modern post-Windows 2003 server in terms
> of the MsvAvTimestamp, which causes us to turn on our
> MIC code, but then don't reply containing a mechlistMIC,
> like a a pre-Windows 2008 server.
> 
> We work against a Windows 2003 server as it never sends
> the MsvAvTimestamp I'd guess, so in that case we don't
> send or expect any mechlistMIC.
> 
> In fact commit 0d641ee36ae2c shows exactly how this
> happened:
> 
> +               if (timestamp != NULL) {
> +                       uint32_t sign_features =
> +                                       GENSEC_FEATURE_SESSION_KEY |
> +                                       GENSEC_FEATURE_SIGN |
> +                                       GENSEC_FEATURE_SEAL;
> +
> +                       server_timestamp = &timestamp-
> >Value.AvTimestamp;
> +
> +                       if (ntlmssp_state->force_old_spnego) {
> +                               sign_features = 0;
> +                       }
> +
> +                       if (gensec_security->want_features &
> sign_features) {
> +                               struct AV_PAIR *av_flags = NULL;
> +
> +                               av_flags =
> ndr_ntlmssp_find_av(&ntlmssp_state->client.av_pair_list,
> +                                                              MsvAvF
> lags);
> +                               if (av_flags == NULL) {
> +                                       av_flags = eol;
> +                                       eol++;
> +                                       count++;
> +                                       *eol = *av_flags;
> +                                       av_flags->AvId = MsvAvFlags;
> +                                       av_flags->Value.AvFlags = 0;
> +                               }
> +
> +                               av_flags->Value.AvFlags |=
> NTLMSSP_AVFLAG_MIC_IN_AUTHENTICATE_MESSAGE;
> +                               ntlmssp_state->new_spnego = true;
> +                       }
> +               }
> 
> note the 'ntlmssp_state->new_spnego = true' when timestamp != NULL.
> 
> And it looks like the Windows client doesn't check the
> mechlistMIC in this case, so we might need to losen our
> check also.
> 
> This would also fix the smbclient connecting to the Microsoft
> Azure server problem - that server also only does NTLM and
> doesn't send the mechlistMIC in the ACCEPT_COMPLETED reply.
> 
> Attached is a possible patch, but I'm *really* unsure
> if this is safe w.r.t. downgrade attacks.
> 
> Metze, can you take a look at this and let me know what you
> think ?

I've been thinking about when a downgrade attack is possible and the
only scenario that comes to mind is when the server just ignores the
client MIC. And in that case the server will never detect nor generate
a mechlistMIC anyway.
If the server checks the client sent mechlistMIC, then the server will
detect a downgrade attack and just drop the session establishment.

Simo.