Bug 15241 - [SECURITY] Samba should require encryption on NETLOGON Schannel
Summary: [SECURITY] Samba should require encryption on NETLOGON Schannel
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.17.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: CVE-2022-38023
  Show dependency treegraph
 
Reported: 2022-11-14 18:57 UTC by Andrew Bartlett
Modified: 2022-12-16 11:53 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bartlett 2022-11-14 18:57:54 UTC
We need to follow Microsoft's lead and require a fully encrypted connection for the NETLOGON Secure channel.  

This is likely to address recent reports of users obtaining session keys for NTLM authentication without further encryption protection (often at this point exploiting ZeroLogon), but if only signing is used then this would be visible routinely, using NetlogonValidationSamInfo4.  Samba addressed that with:

commit 5fe7085e3b18a7879dcb4ac0bc14a1b8ccabb268
Author: Stefan Metzmacher <metze@samba.org>
Date:   Fri Aug 7 13:33:17 2015 +0200

    CVE-2016-2111: s4:rpc_server/netlogon: require DCERPC_AUTH_LEVEL_PRIVACY for validation level 6
    
    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11749
    
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Günther Deschner <gd@samba.org>

We follow because it is safer to encrypt, and safer to follow Microsoft's lead so that future protocol developments that work on this assumption are also safe.
Comment 1 Andrew Bartlett 2022-11-14 19:52:19 UTC
Here is the reference to how folks are abusing NetlogonValidationSamInfo4 to obtain session keys, the same would apply to sign-only secure channel: https://dirkjanm.io/a-different-way-of-abusing-zerologon/
Comment 2 Andrew Bartlett 2022-11-14 20:24:07 UTC
Looking at the code and the risks, I think the least-impact way to allow an exception to the encryption requirement is I've described in the advisory on bug 15240.

That is, just use the server schannel option, which now means encrypted schannel, with exempted clients allowed as per the work done for CVE-2020-1472(ZeroLogon). 

We don't want endless different smb.conf parameters, as each needs to be tested and we don't have much time, and I don't expect this will be needed very often.
Comment 3 Andrew Bartlett 2022-11-16 03:12:21 UTC
It has been hinted at that NetApp might be a client the only supports signing of DCE/RPC, but that no windows client will sign-only by default. 

This may influence our feeling on exceptions, but I still prefer the model being suggested, as ZeroLogon is reasonably well mitigated in other ways.

Speaking with Microsoft, I am advised the reason for encryption is that there are a lot of otherwise just RC4 protected or unprotected protocol elements, inbound and outbound, and this provided overall protection.   (The NetlogonValidationSamInfo4 would be one specific example, if a Windows client were specifically configured not to encrypt).
Comment 4 Andrew Bartlett 2022-12-12 20:58:22 UTC
Opening these bugs to the public, and the core issue that triggered this is now described in a BlackHat Europe Presentation by Tom Tervoort, Principal Security Specialist at Secura.
Comment 5 Andrew Bartlett 2022-12-12 21:03:05 UTC
Removing the embargo tag.  There is nothing particularly special in the information in this bug in terms of security, this is a future hardening as much as anything as far as we are aware.
Comment 6 Stefan Metzmacher 2022-12-16 11:53:42 UTC
This is fixed with the patches for CVE-22-38023 (bug #15240)