Okay, we can't start.
Hello, I'm Fraser, I come from Australia, work at Red Hat on identity management and
PKI solutions, and yeah, talking about Kerberus PK Unit protocol.
So I'll give an overview of the Kerberus authentication protocol, then I will discuss
PK Unit, what its advantages are, how it works, and a short demo.
Then I will discuss the security considerations and give a demonstration of a recently discovered
attack against the implementation of Kerberus PK Unit that we have in free IPA.
So Kerberus is an authentication protocol based on symmetric cryptography, it's a single
sign on protocol so you can authenticate once per day, for example, and using a token from
that initial authentication, you can then authenticate to additional services, hosts
or users in the organisation's infrastructure.
It was started at MIT in the late 80s, the current major version of the protocol is version
five and it came about in the early 90s.
The most recent IETF document describing the base protocol is RFC 4.1.2.0, and that was
from 2005, so even that version is nearly 18 years old, but there have been many extensions
and enhancements since then.
The major implementations are MIT Kerberus, Microsoft Active Directory, Heimdall, and
free IPA or identity management in RHEL, which uses MIT Kerberus under the hood with some
additional extensions.
The parties in the Kerberus authentication protocol are the client, the key distribution
centre and services.
So the key distribution centre or KDC consists of two services that are logically distinct
within the protocol, but typically combined together into this one party, which is called
the KDC.
Users, services and the KDC itself are all represented as principles in a realm.
So a principle is just a name for a user, host or service in the realm, and the realm
is the namespace for those user hosts or services.
So often you'll see one company, one organisation might have one realm, but as companies grow
or have mergers and acquisitions, then typically you'll end up with multiple realms in your
organisation.
Each principle has a long term secret key, which is shared with the KDC.
For users, it's typically derived from a password or passphrase, so using PBKDF2 or
some other key derivation and algorithm.
And for hosts and services, the file is often stored in just in a flat file, which we call
a key tab.
And the authentication tokens themselves, which are exchanged in this protocol, are
called tickets.
So let's do some diagrams.
The parties, clients, server or services, and the KDC.
We can see the client has a key, the server has a key, and the KDC has all of the keys,
including the ticket granting service TGS key, which is one of the KDC services.
So the initial authentication exchange involves what we call an ASREC or authentication service
request.
The client says, hey, it's me, I want to authenticate.
It doesn't necessarily carry any authentication information.
The authentication happens when the KDC responds to the client and the response includes a
session key randomly generated by the KDC encrypted to the client's secret key.
So the client does not authenticate to the KDC.
There are ways that you can do that, but in the base protocol, the authentication happens
because only the client can decrypt the response containing the session key.
The response also contains a ticket called the ticket granting ticket, which is not encrypted
to the client's key, but rather to the ticket granting services key.
It also contains a copy of the session key and some information about the client.
So the client can decrypt the session key and store the ticket granting ticket.
After when the client wants to authenticate to the server, it sends a TGS request to the
KDC saying, I would like to talk to such and such a principle, in this case, a server.
It includes the ticket granting service ticket or TGT, and it also includes a timestamp
for replay attack prevention and some client information encrypted to the session key.
The KDC can use the TGS secret key to decrypt the ticket, pull out the session key, decrypt
the client authenticator, make sure the client info matches up, make sure the timestamp
is within an allowable skew, and if everything checks out, then in the TGS request, it will
send a TGS reply.
The KDC can return a ticket for the server, which contains a new session key, and it also
returns the new session key encrypted under the existing session key for the TGS session.
So the client can decrypt the second session key and store the ticket for the service,
the service ticket, and finally, it can talk to the service.
So it sends the application protocol request, it includes the service ticket, it includes
an authenticator encrypted using the second session key.
The server can then use its long-term secret key to decrypt the ticket, pull out the session
key, and then it can use that session key to decrypt the authenticator, make sure the
client info all lines up, make sure the timestamp is within the allowable skew, and then there's
a shared session key between the client and the server.
They can talk whatever protocol they want to talk using that session key.
Okay, so that's the base Kerberos protocol.
Kerberos has a bunch of extensions and integrations, there's a pre-authentication framework that
allows you to integrate additional authentication mechanisms, such as a TOTP or an HOTP.
There are mechanisms for embedding Kerberos authentication in the GSS API and in SASL,
so that will allow you to use Kerberos authentication with other protocols that support those authentication
frameworks, such as LDAP or SMTP, IMAP, et cetera.
For HTTP, there's a protocol called Spenego or Spengo, and we can also include authorization
information in the tickets which contain additional information about the client, how they authenticated
to the KDC, so this is what we call the authentication indicator extension, and there are other kinds
of authentication data.
For example, Microsoft Active Directory includes what's called a PAC, I can't remember what
that stands for, but Alexander will know.
Forged attribute certificate, there you go, so that's the MS PAC extension, which you'll
frequently see when you're working with Active Directory or Cross Realm trusts.
With Active Directory, that's that final point, I explained that there were situations where
you're dealing with multiple realms, what if principles from one realm need to communicate
or authenticate to principles in a different realm, that is accomplished by trusts and
the Cross Realm authentication mechanisms.
The advantages of Kerberos, well, it's single sign-on which improves efficiency and reduces
password fatigue for users.
The client has to expose their long-term secret only once until the TGT expires, so maybe
once per day at the start of the day logging into your workstation, a single authentication
happens and from then on, you no longer need to explicitly authenticate.
It is resistant to the replay attacks, that's why all of the authenticators include timestamps,
and it works well for HTTP as well as bare network protocols, which is a shortcoming of
the predominantly HTTP centric SSO protocols like SAML and OpenID Connect.
But the problems are, of course, that passwords are not great and dealing with passwords or
the secret keys in key tabs, making sure that they are rotated, making sure that they are
secure in the first place, can be challenging and burdensome with substantial administrative
overhead.
So this brings us to PKINIT, or Public Key Cryptography for Initial Authentication in
Kerberos as the RFC is called.
In this protocol extension, the client can use asymmetric cryptography to authenticate
to the KDC, and the client presents an X509 certificate in its initial authentication
request, as well as a signature made with the public key or the private key corresponding
to the public key contained in the certificate.
The KDC verifies the certificate, the signature and the binding of the key in the certificate
to the client principal, and if everything checks out, it can respond with a response
encrypted either using Diffie-Hellman or some other analogous key agreement algorithm or
another public key encryption algorithm such as direct RSA encryption.
So visualizing this, the client in the Authentication Service request says, hey, it's me client,
but this time it includes some additional pre-authentication data.
It includes a timestamp, and if it wants to use Diffie-Hellman, a client DH value assigned
by its public key, and it includes the X509 certificate containing that public key.
In the KDC, once it has verified everything is happy to proceed, then its response includes
the TGT, and it includes the session key encrypted using the public key algorithm, in this case
Diffie-Hellman, as well as the KDC Diffie-Hellman value that the client will need to compute
the secret with which the session key is encrypted, and then it can decrypt it, store the session
key, store the TGT, and from this point forward, the rest of the protocol is exactly as before.
In free IPA, by default, we can perform the binding of the certificate and key to the
principal object using an exact certificate match only.
So in the principal's LDAP entry, we'll store a complete copy of the certificate.
We optionally support certificate mapping rules that allow you to be a bit more versatile
in how you establish the binding between the certificate and the principal.
For example, if you're using certificates for hosts, you can pull out the DNS name from
the subject alternative name field in the certificate and construct an LDAP query saying,
well, we're looking for hosts whose FQDN matches that DNS name from the certificate.
And the client certificates can be signed by free IPA's internal CA or by a third-party
CA that the KDC trusts.
The user experience for PKInit, you can do it from a CLI, it's not very pleasant, but
you can use SSSD integrated with your login manager to improve that experience, particularly
if you're using smart cards or TPM for storing the private keys, or doing additional pre-authentication
mechanisms like a two-factor authentication, and Windows offers a similar experience.
It should be, in fact, it must be easy for users and friendly for users, otherwise people
will not use it and you will not get the security benefits.
So quick demo, K-list shows me what tickets I currently have, the answer is none.
If I K-init as Alice, I can type Alice's passphrase, and I now have a TGT for Alice,
so that was a password-based authentication, and if I ping the IPA server, that's just
talking to the free IPA HTTP API, now if I K-list, I can see that behind the scenes,
it's a quieter service ticket for one of the IPA HTTP servers, I'll just destroy those
tickets now, and I'll do a PK-init, so if I change directory here, here I have a certificate
and a key, and just pre-print the cert for you, so what can we say about this cert, and
actually I'll tell you what, I'm doing things in the wrong order here, I'm going to do a
host authentication first, so if I do K-init-x, X509, user identity equals file, and the certificate,
and the key, and a host name, not a host name rather, but the principal name, host slash
rel78.IPA.TEST, and K-list, here we have our TGT for the host principal, okay, so PK-init
advantages, no more passwords or client-shared secrets, the keys can reside on the smart
cards, or so for example in a UV key, in a TPM, or in hardware security module, and
as I mentioned earlier, the rest of the protocol after the initial authentication service exchange
is unchanged, which makes it easy for services.
The complexities, well you need an X509PKI, this brings in the renewal considerations
and revocation considerations, the hardware, if you want the benefit of the hardware security
that will cause an additional financial cost to buy the hardware, and binding the public
key to the principal is an important consideration, so in the RFC, it's RFC 4556 it says, the
KDC must also check that the client's public key used to verify the client's signature
is bound to the client principal name specified in the authentication service request, and
it goes on to suggest how you can do that, a couple of ways you can do it, you can encode
the principal name directly in the certificate in a specialised subject alternative name,
or you can associate the certificate or the key directly with the principal in your database,
that is what we have as the default behaviour in free IPA, but that introduces administrative
overhead because when the certificate is renewed or the client re-keys, then you need to make
sure that those entries are up to date, or you can use other heuristics, for example
if the cert has a DNS name, pull that out and use that to look up a host, if the certificate
has an RFC 822 name, which is an email address, pull that out, use it to look up a user principal,
and you better not mess this up, which brings us to the CVE, so if we have a look at the
certificate that I used to get this host principal, we'll see something interesting, it doesn't
actually mention that principal name anywhere, the RAL7 8-0, but it does have a subject alternative
name, it has two in fact, one of them is a wildcard DNS name.
So what's happening here, it's an LDAP filter injection vulnerability, free IPA is not vulnerable
in the default config because as I mentioned only exact certificate matches used by default.
This bug is in the SSSD component, it was already resolved when I found it, so it was
only older but still supported versions that were affected, and the fix has now been released
and the details are public.
So what's happening is that the cert map rule, sorry about that, the cert map rule is just
pulling the DNS name out of the certificate and concatenating it directly into the LDAP
filter without sanitization and in LDAP, asterisk is a substring match character, so using that
certificate would let you get a TGT for any host principal in your realm.
And another interesting question is what happens if this is your email address?
Now this might seem like a stretch but that is a valid email address and I'm sure many
of you work at companies or have worked at companies where you can request your own email
alias at Red Hat, we certainly do.
So if you managed to request an email alias such as this and the system approved it and
you've got a certificate with that email address on it and you have a cert map rule that looks
something like this where you're stuffing the subject RFC A22 name into the query and
using it to look up a mail attribute and that was somehow nested inside an or list expression,
then you've just got yourself a domain takeover.
So let's see a demo of that.
If there's time, there might not be time, I think, how much?
Five minutes left.
So I'm going to skip it.
Sorry.
I'll tell you what, after I finish the talk, if I can, I'll just do it.
But let me discuss now the mitigation.
So yes, if you're running a vulnerable version of SSSD, you should update it.
The and list rules are harder to exploit than all lists.
Just point out how the LDAP filter expressions work, the all list, if you have a single sub
expression, then the whole list expression will match, but an and list you have to match
every sub clause, so it's just easier to exploit an all list.
You should definitely audit what data can get included in certificates, where that data
comes from, and how it's included or encoded in the cert.
And you could use exact certificate matching to avoid this issue, but that does come with
the administrative overheads to handle renewals or re-keys.
General security considerations for PK unit, well, and this first point is for just all
software always, probably escape and sanitize your inputs according to how you're using
them.
You should review your CA trust, so which CAs are you trusting?
What profiles for issuing the certificates are used or templates?
And how are the attributes that go into the certificates validated?
Who can issue the certificates that you trust, both in terms of their software systems and
the agents, human or otherwise, who act to issue certificates?
And can any of the attributes be influenced by users or other parties, such as if you
have your email address alias request system?
Just because a value is valid in a particular context does not mean that it's benign in
another context.
And the key in principle binding is a critical aspect of PK unit security and PKI application
security in general.
It is as critically important as validating your certificate chain and validating signatures.
The full write up about this issue is at that link on my blog.
And there's a link also to the entry about this issue in the Red Hat CVE database which
includes the list of which products were affected and where the fixes have happened
and where they are not happening.
Okay.
And that's also, I'll ask questions and then maybe I do the domain takeover demo in a minute.
Maybe we have time up for one question.
So is there anyone who has the best question that will be answered in one minute?
They want the demo.
Okay.
So let's, I need to just change the cert map rules, which ones are active?
Oops.
If I can authenticate.
Okay.
My PA is cert map rule, find, this is just the set up.
So I need to disable cert map two and enable cert map one.
Okay.
So this is the rule that I'm enabling.
I didn't enable it.
Oh, thank you for that.
Okay.
Now it's enabled.
And I can do K in it.
Let's see it'll be there in the scroll back somewhere.
That's server, that's okay.
So the naughty certificate and the naughty key.
And I want to be admin.
And now I'm admin.
I'm going to show you the certificate.
Okay.
So the certificate was issued to Alice and the subject name includes Alice's malicious
email alias.
Okay.
There you have it.
That's, there you have it.
Bye.
Thank you.
All right.