8.1 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
5.1 Medium
CVSS2
Access Vector
NETWORK
Access Complexity
HIGH
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:H/Au:N/C:P/I:P/A:P
0.091 Low
EPSS
Percentile
94.6%
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.
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.
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:
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
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
8.1 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
5.1 Medium
CVSS2
Access Vector
NETWORK
Access Complexity
HIGH
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:H/Au:N/C:P/I:P/A:P
0.091 Low
EPSS
Percentile
94.6%