===================================================================== CERT-Renater Note d'Information No. 2022/VULN470 _____________________________________________________________________ DATE : 16/12/2022 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Samba versions prior to 4.15.13, 4.16.8, 4.17.4. ===================================================================== https://www.samba.org/samba/security/CVE-2022-38023.html https://www.samba.org/samba/security/CVE-2022-37966.html https://www.samba.org/samba/security/CVE-2022-37967.html https://www.samba.org/samba/security/CVE-2022-45141.html _____________________________________________________________________ CVE-2022-38023.html: =========================================================== == Subject: RC4/HMAC-MD5 NetLogon Secure Channel is weak and should be avoided == == CVE ID#: CVE-2022-38023 == == Versions: All versions of Samba == == Summary: The "RC4" protection of the NetLogon Secure channel uses the == same algorithms as rc4-hmac cryptography in Kerberos, == and so must also be assumed to be weak. =========================================================== =========== 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 Team ========================================================== _____________________________________________________________________ CVE-2022-37966.html: =========================================================== == Subject: rc4-hmac Kerberos session keys issued == to modern servers == == CVE ID#: CVE-2022-37966 == == Versions: All versions of Samba using Kerberos == == Summary: This is the Samba CVE for the Windows Kerberos == RC4-HMAC Elevation of Privilege Vulnerability == disclosed by Microsoft on Nov 8 2022. == == A Samba Active Directory DC will issue weak rc4-hmac == session keys for use between modern clients and servers == despite all modern Kerberos implementations supporting == the aes256-cts-hmac-sha1-96 cipher. == == On Samba Active Directory DCs and members == 'kerberos encryption types = legacy' would force == rc4-hmac as a client even if the server supports == aes128-cts-hmac-sha1-96 and/or aes256-cts-hmac-sha1-96. =========================================================== =========== Description =========== Kerberos, the trusted third party authentication system at the heart of Active Directory, issues a session key known to the target server and the client, encrypted to both services in a TGS-REP. The key algorithm chosen for here is then used for the subsequent signed or encrypted connection (eg GSSAPI secured LDAP or DCE/RPC). The kerberos rc4-hmac (also known as arcfour-hmac-md5) cipher is weak, as the 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 an signed but un-encrypted data stream without being detected. (Encrypted connections, which are more typical, are not impacted). Because of the earlier MD5 step, the protection of the HMAC is bypassed and an attacker does not need to know the key. For successful communication, the session key needs to be of a type understood by all parties. Traditionally it was assumed that the administrator would provision the strongest long term key possible for the software on the Kerberos target, so this long-term key list was also used as the set of possible session keys. This is a reasonable assumption where regular updates to msDS-SupportedEncryptionTypes are made, however if this is not updated, the default has been the rc4-hmac (arcfour-hmac-md5) cipher introduced in Active Directory in Windows 2000. It is not possible to, without specific testing, update msDS-SupportedEncryptionTypes to include the AES cipher bits arbitrarily (the target may not have AES keys in the keytab, or may have the wrong salt), but it is reasonable in 2022 to assert that all Kerberos client and server software support the aes256-cts-hmac-sha1-96 cipher. After this update, the fallback for an unspecified msDS-SupportedEncryptionTypes (either no value or explicit "0") becomes "rc4-hmac, aes256-cts-hmac-sha1-96-sk" by default. The fallback value can be controlled by the "kdc default domain supported enctypes" smb.conf option if required. aes256-cts-hmac-sha1-96-sk (bit 0x20 in msDS-SupportedEncryptionTypes) is a non-IETF keytype name with the behaviour that regardless of the ticket key encryption type selected (for example rc4-hmac, being the insecure algorithm being avoided, Samba does not support DES), that aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 session keys can still be negotiated. However, the ticket itself will still be encrypted with rc4-hmac. The preferred solution is in the Workaround below. Note that after this update, the fallback for an unspecified msDS-SupportedEncryptionTypes (either no value or explicit "0") for trustedDomain objects are changed in an incompatible way! The fallback is now aes256-cts-hmac-sha1-96 instead of rc4-hmac! It is therefor recommended to explicitly set the value on both sides of the trust before or immediately after the update. See more details in the Workaround below. ================== 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:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1) It is noted that this score matches Microsoft's for the same issue. Despite this value, please note that this attack requires: * that the connection not be encrypted, only signed * that an active attacker obtains a plaintext value of the packet * and can find another plaintext value with the same MD5 checksum and replace it undetected. ============================ Workaround and long-term fix ============================ After confirming a valid key of aes256-cts-hmac-sha1-96 is present in the target service keytab setting msDS-SupportedEncryptionTypes to (base 10) 16 on that service's account in LDAP will avoid using rc4-hmac entirely. AES256 support can also be set in Active Directory Users and computers. In some situations winbindd (as AD DC or AD domain member), as well as tools like 'net' generate/use a custom krb5.conf file. Using the option "kerberos encryption types = legacy" will force rc4-hmac and disable aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 support. In 2022 there's no longer any reason to use "kerberos encryption types = legacy"! Also inspect your global /etc/krb5.conf and make sure it doesn't disable aes256-cts-hmac-sha1-96. For trusted domains you should explicitly configure the use of aes256-cts-hmac-sha1-96 support, either via the Windows GUI or the newly added 'samba-tool domain trust modify --use-aes-keys'. For legacy trusts against Windows 2000/2003 domains you need to force rc4-hmac using 'samba-tool domain trust modify --no-aes-keys'. Against remote DCs (including Windows) you can use the --local-dc-ipaddress= and other --local-dc-* options. See 'samba-tool domain trust modify --help' for further details. Note that already cached rc4-hmac cross-realm tickets may no longer work after switching to aes, which may cause temporary problems. Setting a 1 hour ticket lifetime may reduce the problems: kdc:user_ticket_lifetime = 1 ======= Credits ======= Originally reported to Microsoft by Tom Tervoort with Secura https://www.secura.com/ and released as CVE-2022-37966. Advisory written by Andrew Bartlett of Catalyst and the Samba Team. Patches provided by Joseph Sutton of Catalyst and the Samba Team. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ========================================================== _____________________________________________________________________ CVE-2022-37967.html: =========================================================== == Subject: Kerberos constrained delegation ticket == forgery possible against Samba AD DC == == CVE ID#: CVE-2022-37967 == == Versions: All versions of the Samba AD DC == == Summary: This is the Samba CVE for the Windows == Kerberos Elevation of Privilege Vulnerability == disclosed by Microsoft on Nov 8 2022[1]. == == A service account with the special constrained == delegation permission could forge a more powerful == ticket than the one it was presented with. =========================================================== =========== Description =========== Kerberos constrained delegation, known also as S4U2Proxy, requires that the intermediate service present to the KDC a valid Kerberos ticket (including the PAC) obtained by the user as evidence that they had authenticated, so that a new ticket can be issued for the target server. The Kerberos PAC is signed in multiple stages, but the important protection of the SID list (list of user groups) in the PAC is done first with the server's key, and then with the krbtgt key over that result. However the rc4-hmac cipher as implemented in Kerberos is weak in 2022, for two reasons: * The implementation in Kerberos is HMAC-MD5(MD5(DATA),KEY), meaning that the attack on the PAC can be done using the chosen-prefix techinques for MD5 without knowing the key * The intermediate server knows its own password (the key used in the HMAC-MD5 step) and can set it to arbitrary values. It is therefore feasible to brute force a new server checksum that matches the value already signed by the krbtgt key, but including a privileged group in the PAC. ================== 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:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2) ==================== Workaround and notes ==================== This issue can be worked around by disable delegation for services that are not fully trusted, or securing these services to the same standard as the DC itself. Note that this patch introduces a flag day, there is no partial rollout of this feature (unlike KrbtgtFullPacSignature in Microsoft Windows[2]), so service tickets issued prior to the update will be rejected as evidence tickets for Kerberos constrained delegation. While Kerberos constrained delegation (S4U2Proxy) is not a often-used feature with Samba AD DCs, setting a 1 hour ticket lifetime: kdc:service_ticket_lifetime = 1 and waiting for any existing tickets to expire would reduce the number of tickets that are not accepted. Also ensure all DCs are upgraded around the same time, as if a ticket is issued by a pre-upgrade DC it will not be accepted by a new DC for Kerberos constrained Delegation. ========== References ========== [1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37967 [2] https://support.microsoft.com/en-us/topic/kb5020805-how-to-manage-kerberos-protocol-changes-related-to-cve-2022-37967-997e9acc-67c5-48e1-8d0d-190269bf4efb ======= Credits ======= Originally reported to Microsoft by Tom Tervoort of Secura. Advisory written by Andrew Bartlett of Catalyst and the Samba Team. Patches provided by Joseph Sutton of Catalyst and the Samba Team. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ========================================================== _____________________________________________________________________ CVE-2022-37967.html: =========================================================== == Subject: Kerberos constrained delegation ticket == forgery possible against Samba AD DC == == CVE ID#: CVE-2022-37967 == == Versions: All versions of the Samba AD DC == == Summary: This is the Samba CVE for the Windows == Kerberos Elevation of Privilege Vulnerability == disclosed by Microsoft on Nov 8 2022[1]. == == A service account with the special constrained == delegation permission could forge a more powerful == ticket than the one it was presented with. =========================================================== =========== Description =========== Kerberos constrained delegation, known also as S4U2Proxy, requires that the intermediate service present to the KDC a valid Kerberos ticket (including the PAC) obtained by the user as evidence that they had authenticated, so that a new ticket can be issued for the target server. The Kerberos PAC is signed in multiple stages, but the important protection of the SID list (list of user groups) in the PAC is done first with the server's key, and then with the krbtgt key over that result. However the rc4-hmac cipher as implemented in Kerberos is weak in 2022, for two reasons: * The implementation in Kerberos is HMAC-MD5(MD5(DATA),KEY), meaning that the attack on the PAC can be done using the chosen-prefix techinques for MD5 without knowing the key * The intermediate server knows its own password (the key used in the HMAC-MD5 step) and can set it to arbitrary values. It is therefore feasible to brute force a new server checksum that matches the value already signed by the krbtgt key, but including a privileged group in the PAC. ================== 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:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2) ==================== Workaround and notes ==================== This issue can be worked around by disable delegation for services that are not fully trusted, or securing these services to the same standard as the DC itself. Note that this patch introduces a flag day, there is no partial rollout of this feature (unlike KrbtgtFullPacSignature in Microsoft Windows[2]), so service tickets issued prior to the update will be rejected as evidence tickets for Kerberos constrained delegation. While Kerberos constrained delegation (S4U2Proxy) is not a often-used feature with Samba AD DCs, setting a 1 hour ticket lifetime: kdc:service_ticket_lifetime = 1 and waiting for any existing tickets to expire would reduce the number of tickets that are not accepted. Also ensure all DCs are upgraded around the same time, as if a ticket is issued by a pre-upgrade DC it will not be accepted by a new DC for Kerberos constrained Delegation. ========== References ========== [1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37967 [2] https://support.microsoft.com/en-us/topic/kb5020805-how-to-manage-kerberos-protocol-changes-related-to-cve-2022-37967-997e9acc-67c5-48e1-8d0d-190269bf4efb ======= Credits ======= Originally reported to Microsoft by Tom Tervoort of Secura. Advisory written by Andrew Bartlett of Catalyst and the Samba Team. Patches provided by Joseph Sutton of Catalyst and the Samba Team. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ========================================================== _____________________________________________________________________ CVE-2022-45141.html: =========================================================== == Subject: Samba AD DC using Heimdal can be forced to == issue rc4-hmac encrypted Kerberos tickets == == CVE ID#: CVE-2022-45141 == == Versions: Heimdal builds of the Samba AD DC prior to Samba 4.16 == == Summary: Since the Windows Kerberos RC4-HMAC Elevation of Privilege == Vulnerability was disclosed by Microsoft on Nov 8 2022 == and per RFC8429 it is assumed that rc4-hmac is weak, == == Vulnerable Samba Active Directory DCs will issue rc4-hmac == encrypted tickets despite the target server supporting == better encryption (eg aes256-cts-hmac-sha1-96). =========================================================== =========== Description =========== Kerberos, the trusted third party authentication system at the heart of Active Directory, issues a ticket using a key known to the target server but nobody else, returned to the client in a TGS-REP. This key needs to be of a type understood only by the KDC and target server. However, due to a coding error subsequently addressed in all recent Heimdal versions and so fixed with Samba 4.16 (which imports Heimdal 8.0pre), the (attacking) client would be given the opportunity to select the encryption type, and so obtain a ticket encrypted with rc4-hmac, that it could attack offline. This is possible unless rc4-hmac is totally removed from the server's account, by removing the unicodePwd attribute, but this will break other aspects of the server's operation in the domain (NETLOGON in particular). ================== Patch Availability ================== Patches addressing both these issues have been posted to: https://www.samba.org/samba/security/ Additionally, Samba 4.15.13 has 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:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1) ================ (not) Workaround ================ Setting msDS-SupportedEncryptionTypes is not a workaround for this issue. ======= Credits ======= Originally reported by Joseph Sutton of Catalyst and the Samba Team. Advisory written by Andrew Bartlett of Catalyst and the Samba Team. Patches by Nicolas Williams were identified and backported by Joseph Sutton of Catalyst and the Samba Team. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ========================================================== ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================