Bug 1134024 (CVE-2018-16860)

CVE-2018-16860

CRD: 2019-05-14

https://bugzilla.samba.org/show_bug.cgi?id=13685

===========================================================
== Subject:     Samba AD DC S4U2Self/S4U2Proxy unkeyed checksum
==
== CVE ID#:     CVE-2018-16860
==
== Versions:    All Samba versions since Samba 4.0
==              All releases of Heimdal from 0.8 including 7.5.0
==		and any products that ship a KDC derived from one of
==              those Heimdal releases.
==
== Summary:     The checksum validation in the S4U2Self handler in
==              the embedded Heimdal KDC did not first confirm that the
==              checksum was keyed, allowing replacement of the
==              requested target (client) principal.
===========================================================

===========
Description
===========

S4U2Self is an extension to Kerberos used in Active Directory to allow
a service to request a kerberos ticket to itself from the Kerberos Key
Distribution Center (KDC) for a non-Kerberos authenticated user
(principal in Kerboros parlance). This is useful to allow internal
code paths to be standardized around Kerberos.

S4U2Proxy (constrained-delegation) is an extension of this mechanism
allowing this impersonation to a second service over the network. It
allows a privileged server that obtained a S4U2Self ticket to itself
to then assert the identity of that principal to a second service and
present itself as that principal to get services from the second
service.

There is a flaw in Samba's AD DC in the Heimdal KDC. When the Heimdal
KDC checks the checksum that is placed on the S4U2Self packet by the
server to protect the requested principal against modification, it
does not confirm that the checksum algorithm that protects the user
name (principal) in the request is keyed.  This allows a
man-in-the-middle attacker who can intercept the request to the KDC to
modify the packet by replacing the user name (principal) in the
request with any desired user name (principal) that exists in the KDC
and replace the checksum protecting that name with a CRC32 checksum
(which requires no prior knowledge to compute).

This would allow a S4U2Self ticket requested on behalf of user name
(principal) user@EXAMPLE.COM to any service to be changed to a
S4U2Self ticket with a user name (principal) of
Administrator@EXAMPLE.COM. This ticket would then contain the PAC of
the modified user name (principal).

==================
Patch Availability
==================

Patches addressing both these issues have been posted to:

    http://www.samba.org/samba/security/

Additionally, Samba 4.8.12, 4.9.8 and 4.10.3 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.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (7.5)

=========================
Workaround and Mitigation
=========================

If server does not take privileged actions based on Kerberos tickets
obtained by S4U2Self nor obtains Kerberos tickets via further
S4U2Proxy requests then this issue cannot be exploited.

Note that the path to an exploit is not generic, the KDC is not harmed
by the malicious checksum, it is the client service requesting the
ticket being mislead, because it trusted the KDC to return the correct
ticket and PAC.

It is out of scope for Samba to describe all of the possible tool
chains that might be vulnerable. Here are two examples of possible
exploits in order to explain the issue more clearly.

1). SFU2Self might be used by a web service authenticating an end user
via OAuth, Shibboleth, or other protocols to obtain a S4U2Self
Kerberos service ticket for use by any Kerberos service principal the
web service has a keytab for.  One example is acquiring an AFS token
by requesting an afs/cell@REALM service ticket for a client via
SFU2Self.  With this exploit an organization that deploys a KDC built
from Heimdal (be it Heimdal directly or vendor versions such as found
in Samba) is vulnerable to privilege escalation attacks.

2). If a server authenticates users using X509 certificates, and then
uses S4U2Self to obtain a Kerberos service ticket on behalf of the
user (principal) in order to authorize access to local resources, a
man-in-the-middle attacker could allow a non-privilaged user to access
privilaged resources being protected by the server, or privilaged
resources being protected by a second server, if the first server uses
the S4U2Proxy extension in order to get a new Kerberos service ticket
to obtain access to the second server.

In both these scenarios under conditions allowing man-in-the-middle
active network protocol manipulation, a malicious user could
authenticate using the non-Kerborized credentials of an unprivileged
user, and then elevate its privileges by intercepting the packet from
the server to the KDC and changing the requested user name (principal).

The only Samba clients that use S4U2Self are:

- the "net ads kerberos pac dump" (debugging) tool.

- the CIFS proxy in the deprecated/developer-only NTVFS file
server. Note this code is not compiled or enabled by default.

In particular, winbindd does *not* use S4U2Self.

Finally, MIT Kerberos and so therefore the experimental MIT KDC backend
for Samba AD is understood not to be impacted.

===============
Further Reading
===============

There is more detail on and a description of the protocols in 

[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/

=======
Credits
=======

Originally reported by Isaac Boukris and Andrew Bartlett of the Samba
Team and Catalyst.

Patches provided by Isaac Boukris.

Advisory written by Andrew Bartlett of the Samba Team and Catalyst,
with contributions from Isaac Boukris, Jeffrey Altman and Jeremy
Allison.

==========================================================
== Our Code, Our Bugs, Our Responsibility.
== The Samba Team
==========================================================