## Description

This is Samba’s response to Microsoft’s CVE-2022-38023[1][2].

Following RFC8429 and as has been published for CVE-2022-3938, rc4-hmac
(also known as arcfour-hmac-md5) cryptography in Kerberos is weak,
then it follows that the RC4 mode in the NETLOGON Secure Channel
(DCE/RPC bulk encryption) is also weak, as they are the same cipher
(essentially).

The weakness on NetLogon Secure channel is that the secure checksum is
calculated as HMAC-MD5(MD5(DATA),KEY), meaning that an active attacker
knowing the plaintext data could create a different chosen DATA, with
the same MD5 checksum, and substitute it into the data stream without
being detected.

Therefore we must disable this cipher.

In this patch we achive this by setting ‘reject md5 clients = yes’ and
‘reject md5 servers = yes’ by default.

Thankfully this cipher is unused by most modern member servers,
including Windows 7 / Windows 2008R2 and later, as well as
Samba 4.0 and later, however public documentation suggests[1]
that NetApp ONTAP still uses RC4 (HMAC-MD5).

The following smb.conf:

reject md5 clients = yes # the new default
server reject md5 schannel:TRICERATOPS$ = no
server reject md5 schannel:GREYWACKE$ = no

will allow only “TRICERATOPS$” and “GREYWACKE$” to use RC4 (HMAC-MD5)
crypography.

If you really need to support legacy DES based clients, it is now
also possible to allow them explicitly:

allow nt4 crypto = no # the default
reject md5 clients = yes # the new default
allow nt4 crypto:NT4CLIENT$ = yes
server reject md5 schannel:NT4CLIENT$ = no

Additionally we extend default to requiring a full encrypted NETLOGON
secure channel.

Encryption of the secure channel not only provides overall privacy
(particularly against attacks on the individually encrypted elements
within the NETLOGON protocol), it also strengthens the RC4 (HMAC-MD5)
cipher.

Clients that do not support NETLOGON Secure Channel encryption can be
exempted in a similar way.

The following smb.conf:

server schannel require seal = yes # the default
server schannel require seal:TRICERATOPS$ = no
server schannel require seal:GREYWACKE$ = no

will allow only “TRICERATOPS$” and “GREYWACKE$” to avoid encrypted
schannel and operate with signing-only schannel.

For clients without any netlogon “sign or seal” transport protection
you will need something like this:

server schannel = yes # the default
server schannel require seal = yes # the default
server require schannel:NT4CLIENT$ = no
server schannel require seal:NT4CLIENT$ = no
## Patch Availability

Patches addressing both these issues have been posted to:

https://www.samba.org/samba/security/

Additionally, Samba 4.15.13, 4.16.8 and 4.17.4 have been issued
as security releases to correct the defect. Samba administrators are
advised to upgrade to these releases or apply the patch as soon
as possible.
## CVSSv3 calculation

CVSS:v3.1:AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1)

Despite this value, please note that this attack requires:
* that the connection not be encrypted (which is the default)
* that an active attacker obtains a plaintext value of a packet in the NetLogon Secure Channel
* and can find another plaintext value with the same MD5 checksum and
replace it undetected.
## Workaround and notes

Setting ‘reject md5 clients = yes’ (on DCs) and ‘reject md5 servers = yes’
(on DCs and member servers) will avoid this vulnerable protocol,
but this will reject legacy clients which have worked before.

‘winbind sealed pipes = yes’ should also be kept at its default value!

Regarding the encryption requirement, thankfully Samba addressed
SamLogon NTLM session key disclosure issue in CVE-2016-2111.

In preparation of the update to the new Samba version on an AD DC
would could try to identify legacy clients from (JSON) audit logs
(if configured). You can find domain member servers that use
AES (HMAC-SHA256) vs RC4 (HMAC-MD5) via the passwordType
element.

Note that un-important keys have been dropped for brevity:

{
“type”: “Authentication”,
“Authentication”: {
“remoteAddress”: “ipv4:10.53.57.29:37589”,
“serviceDescription”: “NETLOGON”,
“authDescription”: “ServerAuthenticate”,
“clientAccount”: “LOCALADMEMBER$”,
“becameSid”: “S-1-5-21-626540054-1513162547-2555510494-1114”,
“passwordType”: “HMAC-SHA256”
}
}

{
“type”: “Authentication”,
“Authentication”: {
“remoteAddress”: “ipv4:10.53.57.11:37767”,
“serviceDescription”: “NETLOGON”,
“authDescription”: “ServerAuthenticate”,
“clientAccount”: “SAMLOGONTEST$”,
“becameSid”: “S-1-5-21-626540054-1513162547-2555510494-1115”,
“passwordType”: “HMAC-MD5”
}
}

With that information you could pre-add lines like this to
your smb.conf:

server reject md5 schannel:SAMLOGONTEST$ = no

As alternative or in addition you could explicitly configure
the insecure (former) defaults for a short grace period (of a few days):

reject md5 clients = no
server schannel require seal = no

Subsequently monitor the log files for messages containing the strings
“CVE-2022-38023” or “CVE-2020-1472”, they contain indications for
missing explicit per client configuration lines. You should
copy those lines to your smb.conf on a regular basis.
After some time, when those messages are no longer logged,
it is safe to remove the insecure (former) defaults and leave
the new defaults in place. See ‘man smb.conf’ for more details.

Even with the new secure defaults it is useful to monitor the
log files in order to identify clients, which are now rejected.
## References

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-38023
[2] https://support.microsoft.com/en-us/topic/kb5021130-how-to-manage-the-netlogon-protocol-changes-related-to-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25
[3] https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Microsoft_Security_Advisory%3A_CVE-2020-1472_impact_on_NetApp_appliance_running_CIFS_NFS_utilizing_Netlogon_servers
## Credits

Microsoft reported this issue at
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-38023

Patches provided by Stefan Metzmacher of SerNet and the Samba team.

Advisory written by Andrew Bartlett of Catalyst and the Samba Team.

== Our Code, Our Bugs, Our Responsibility.
== The Samba TeamRead More