== 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.


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:

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


Originally reported to Microsoft by Tom Tervoort with Secura 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