On Пят, 02 лют 2024, Tomasz Torcz via FreeIPA-users wrote:
On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via
FreeIPA-users wrote:
> On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
> > Is there anyway to just delete all these SID requirements? My ipa
> > domain doesn't have a trust to anything windows and there's no plan to
> > ever set that up.
>
> No.
>
> S4U protocol extensions for Kerberos are requiring PAC buffers presence
> as per the MS-SFU spec. The changes came in in 2021 as a part of the
> fixes to 'dollar sign attack'. You can get a partial view of that with
>
https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or
> several talks we gave over past few years at various conferences. Most
> notable:
> - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket
Attack"
>
https://www.youtube.com/watch?v=1BnraIAcybg
>
> - Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT
> Kerberos: path out of experimental"
>
https://www.youtube.com/watch?v=0_cdYuIYw0o
Those attacks are against MS Windows (and Samba?)
I would say they're not relevant to majority of FreeIPA deployments,
which have nothing to do with Windows.
You are wrong here. It is a common problem since majority of users do not
understand Kerberos protocol extensions and their use by FreeIPA or
other domain services like Samba AD or Active Directory.
Since its inception, FreeIPA has depended on S4U extensions to Kerberos
to allow IPA services operate on behalf of users. This is used by IPA
API, for example, to allow IPA management framework to talk to LDAP on
behalf of the user and LDAP server to recognize that this connection is
authenticated as the user, not IPA management framework account.
This extension was developed by Microsoft for Active Directory to allow
domain member machines to operate on behalf of the user when mounting
home directories (shares) or allowing web servers to ask for other
resources (file shares or SQL server connections) on behalf of the user.
All these technical elements are part of a constrained delegation
feature that both Active Directory implementations and FreeIPA are using
internally. You can read about constrained delegation forms in more
details in [1].
There are several different attacks that were developed against S4U
extensions and they are protocol level attacks.
A Kerberos ticket received by the service through S4U2Self extension is
supposed to be non-forwardable but 'forwardable' bit is placed in the
area which is under control of the service asking for the ticket.
Hence, a rogue service can flip the 'forwardable' bit and KDC will not
be able to tell the difference: the area is checksummed with a key based
on the service's key. It was supposed to be a protocol extension that
only allowed issuing tickets to itself and not allowing to use it
elsewhere. It is not anymore: this bit flip allows to use a ticket
printed by the rogue service against any other allowed service in the
environment using the second part of S4U extensions, S4U2Proxy. The
latter is the extension used by IPA as the core one for IPA API
operations.
To prevent this attack, a protocol change was added to introduce
additional checksums which aren't under control of the rogue service.
There are actually two separate checksums: one them was found to be
possible to attack via pre-imaging operation against the hash algorithm,
so another one was added to close the problem down.
The only way to prevent these attacks on the checksums and Kerberos
ticket properties was by introducing additional details in the tickets
that cannot be controlled by the attackers. This is done via a set of
extensions that handle authorization data (AD) information in the
Kerberos tickets. MS-PAC describes one of AD buffer types and PAC
records are required for S4U operations. Use of S4U operations since
2020 requires several types of PAC records, all protected from
modifications.
On top of that, use of Kerberos tickets without PAC information opens an
easy attack vector to POSIX environments. PAC allows KDC to place
identity details into Kerberos tickets so that Kerberos services can
corelate Kerberos principal with the information they know about
identity of this principal in their environment. Since SSSD and Samba
(winbindd) do explicit SID to POSIX user/group name translation,
information from PAC records can be used to identify not just the
Kerberos principal to POSIX account/group mapping but also to figure out
whether this principal is of right shape (e.g. it is a valid user rather
than a service or a machine account). This prevents mistyping attacks
like mapping a machine account 'root$' to 'root' POSIX user.
People in both white hat and black hat communities weren't really
attacking FreeIPA through these issues because most of the tools they
use lack features required by the Kerberos implementation in FreeIPA.
For example, FreeIPA defaults to newer Kerberos encryption types defined
in RFC 8009 which Windows still do not support. Neither those common
tools (e.g. Rubeus, Impacket, etc.) have support for newer checksums.
Over past three years some of those tools were fixed so what
required using C code and MIT or Heimdal Kerberos directly is more
accessible to wider public now. In addition to that, Samba AD fixes to
the same issues led to creation of extensive Kerberos test suite that
all of us are using for conformance. Obviously, it is a double-edged
sword in the IT warfare.
Julien Rische did a talk[2] at FOSDEM 2024 to explain how these attacks
work in detail. This is result of a work we did to backport some of the
protection work to RHEL 8 releases. RHEL 8 uses older MIT Kerberos
version which cannot be fixed the same way as RHEL 9 due to ABI
incompatibilities and ACG guaranties RHEL 8 gives. We relied on the
presence of PAC and certain information that FreeIPA KDB driver posseses
about the Kerberos principals to prevent those attacks.
[1]
https://freeipa.readthedocs.io/en/latest/designs/rbcd.html
[2]
https://fosdem.org/2024/schedule/event/fosdem-2024-2681-fixing-a-kerberos...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland