Kerberos PKINIT: what, why, and how (to break it)
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61963 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Kerberos <Kryptologie>Demo (music)Information securityText editorCryptographyCommunications protocolAuthenticationService (economics)Active DirectoryIdentity managementClient (computing)Distribution (mathematics)Raw image formatPrincipal idealPasswordServer (computing)InformationIdentity managementSymmetric-key algorithmCommunications protocolSingle sign-onAuthenticationInformation securityKerberos <Kryptologie>Key (cryptography)PasswordServer (computing)Client (computing)Line (geometry)Service (economics)Dependent and independent variablesInformationDistribution (mathematics)AlgorithmData storage deviceEncryptionField extensionCartesian coordinate system2 (number)Term (mathematics)TimestampRevision controlAdditionImplementationSinc functionExecution unitNamespaceFreewareSelf-organizationDemo (music)Message passingComputer fileDiagramComputer animation
07:09
Communications protocolKerberos <Kryptologie>Client (computing)Text editorSoftware frameworkMechanism designAuthenticationPressure volume diagramDisintegrationField extensionSingle-precision floating-point formatPasswordInformation overloadComputer networkRotationSign (mathematics)Public key certificateMessage passingCryptographyRaw image formatElectronic signatureKeyboard shortcutDependent and independent variablesAlgorithmAnalogyEncryptionPersonal identification numberInformationDefault (computer science)Texture mappingRule of inferenceLoginPlastikkarteSimilarity (geometry)Public key certificateLoginKey (cryptography)AuthenticationObject (grammar)Principal idealData storage devicePoint (geometry)Direct numerical simulationExterior algebraInformation securityMatching (graph theory)BitPublic-key cryptographyField (computer science)Single sign-onUser interfaceRSA (algorithm)Digital rights managementQuery languageClient (computing)Kerberos <Kryptologie>Electronic signatureInclusion mapDependent and independent variablesAuthorizationSoftware frameworkAdditionCommunications protocolService (economics)Directory serviceAlgorithmInformationExtension (kinesiology)Connected spaceTerm (mathematics)Direction (geometry)Multiplication signPasswordTexture mappingCASE <Informatik>Rule of inferenceField extensionPrice indexINTEGRALAttribute grammarInformation overloadComputer networkCryptographyOverhead (computing)TimestampPlastikkarteComputer animation
14:14
PasswordSoftware testingPrincipal idealMetreGraphical user interfaceDemo (music)Type theoryService (economics)DemoscenePasswordPublic key certificateDirectory service
15:18
AuthenticationOrder (biology)AuthenticationPrincipal ideal
16:14
PasswordClient (computing)Public-key infrastructureRenewal theoryComputer hardwarePlastikkartePrincipal idealPersonal identification numberElectronic signatureRaw image formatAdditionPublic key certificateKeyboard shortcutKerberos <Kryptologie>Storage area networkExtension (kinesiology)Formal verificationIntegral domainDatabaseHeuristicOverhead (computing)Address spaceEmailEmailPrincipal idealComputer hardwareAuthenticationInformation securityPasswordCommunications protocolClient (computing)Exterior algebraPublic key certificateDirect numerical simulationService (economics)Renewal theoryDefault (computer science)FreewareKey (cryptography)Computer animation
18:14
Wide area networkSoftware testingGame theoryDistribution (mathematics)Numerical digitAuthenticationWorld Wide Web ConsortiumRSA (algorithm)Electronic signatureCryptographyPublic key certificateServer (computing)Principal ideal
18:36
AuthenticationDistribution (mathematics)AlgorithmWorld Wide Web ConsortiumInjektivitätDigital filterDefault (computer science)Configuration spacePublic key certificateEmailAddress spaceSoftware testingTime domainDirect numerical simulationDemo (music)Software bugMatching (graph theory)EmailRule of inferenceConfiguration spaceFreewareAliasingDefault (computer science)Validity (statistics)Filter <Informatik>Physical systemPublic key certificateBoolean algebraQuery languagePrincipal idealRevision controlComputer animation
20:35
MathematicsAlgorithmAuthenticationPrincipal idealGamma functionRule of inferenceMatching (graph theory)Public key certificateoutputKeyboard shortcutInformation securityAttribute grammarDatabaseLink (knot theory)Rule of inferenceElectronic mailing listFilter <Informatik>Public key certificateExpressionOverhead (computing)Term (mathematics)Physical systemPoint (geometry)Profil (magazine)Information securityBoolean algebraSoftwareKey (cryptography)outputCartesian coordinate systemContext awarenessAttribute grammarRevision controlEmailProduct (business)Link (knot theory)Vulnerability (computing)Demo (music)Domain nameMultiplication signComputer animation
23:59
Wireless Markup LanguageSoftware testingPasswordPhase transitionPrincipal idealColor managementMaxima and minimaExecution unitServer (computing)1 (number)Texture mappingRule of inference
24:20
PasswordTexture mappingRule of inferenceError messageDegree (graph theory)World Wide Web ConsortiumSet-top boxTexture mappingRule of inference
24:56
Texture mappingRule of inferenceError messagePasswordSoftware testingIcosahedronInformation managementGamma functionPublic key certificate
25:28
Texture mappingWorld Wide Web ConsortiumManufacturing execution systemError messagePasswordLie groupSoftware testingGamma functionAlgorithmUniform boundedness principleDistribution (mathematics)AuthenticationRSA (algorithm)Public key certificate
25:50
AuthenticationRule of inferenceError messagePublic key certificateTexture mappingPrincipal idealPasswordWorld Wide Web ConsortiumSoftware testingEvent horizonCache (computing)Maxima and minimaSlide ruleEmailBlogAliasingComputer animation
26:12
Program flowchart
Transcript: English(auto-generated)
00:11
Hello, I'm Fraser, I come from Australia, work at Red Hat on identity management and
00:24
PKI solutions. Talking about Kerberos PK unit protocol. So I'll give an overview of the Kerberos authentication protocol, then I will discuss PK-init, what its advantages are, how it works, and a short demo.
00:43
Then I will discuss the security considerations and give a demonstration of a recently discovered attack against the implementation of Kerberos PK-unit that we have in free IPA.
01:01
So Kerberos 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
01:22
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 5 and it came about in the early 90s.
01:42
The most recent IETF document describing the base protocol is RFC 4120, and that was from 2005, so even that version is nearly 18 years old, but there have been many extensions
02:01
and enhancements since then. The major implementations are MIT Kerberos, Microsoft Active Directory, Heimdall, and free IPA or identity management in RHEL, which uses MIT Kerberos under the hood with some additional extensions.
02:23
The parties in the Kerberos 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
02:41
within the protocol but typically combine together into this one party which is called the KDC. Users, services and the KDC itself are all represented as principles in a RHELM. So a principle is just a name for a user, host or service in the RHELM, and the RHELM
03:02
is the namespace for those user, hosts or services. So often you'll see one company, one organisation might have one RHELM, but as companies grow or have mergers and acquisitions, then typically you'll end up with multiple RHELMs in your organisation.
03:20
Each principle has a long term secret key which is shared with the KDC. For users it's typically derived from a pass word or pass phrase, so using PBKDF2 or some other key derivation algorithm. And for hosts and services the file is often stored in a flat file which we call a key
03:45
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
04:04
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 AS rec or authentication
04:21
service request, the client says hey, it's me, I want to authenticate. Actually 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.
04:46
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.
05:01
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.
05:24
Later when the client wants to authenticate to the server it sends a TGS request to the server. It includes the ticket granting service ticket or TGT and it also includes a time stamp
05:47
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
06:02
key, decrypt the client authenticator, make sure the client info matches up, make sure the time stamp is within an allowable SKU and if everything checks out then in the TGS reply the KDC can return a ticket for the server which contains a new session
06:25
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
06:41
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
07:03
use that session key to decrypt the authenticator, make sure the client info all lines up, make sure the time stamp is within the allowable SKU 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.
07:23
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.
07:42
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.
08:01
For HTTP there's a protocol called Spinego or Spengo and we can also include authorisation 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
08:22
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, Privileged Attributes Certificate, there you go, so that's the
08:41
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
09:00
communicate or authenticate to principles in a different realm, that is accomplished by a trust and the cross realm authentication mechanisms. So 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
09:24
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.
09:41
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.
10:07
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
10:26
overhead. So this brings us to PK-init, or public key cryptography for initial authentication in Kerberos, as the RFC is called. In this protocol extension the client can use
10:42
asymmetric cryptography to authenticate to the KDC, and the client presents an X.509 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.
11:06
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
11:21
encrypted, either using Diffie-Hellman or some other analogous key agreement algorithm, or another public key encryption algorithm such as direct RSA encryption. So, visualising this, the client in the authentication service request says, hey, it's me client,
11:41
but this time it includes some additional pre-authentication data. It includes a time stamp and if it wants to use Diffie-Hellman, a client DH value, assigned by its public key, and it includes the X.509 certificate contained in that public key.
12:01
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
12:27
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 FreeIPA, by default, we can perform the binding of the certificate and key to
12:45
the principal object using an exact certificate match only, so in the principles ALDAP entry will 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
13:02
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 ALDAP query saying we're looking for hosts whose FQDN matches that
13:24
DNS name from the certificate. And the client's certificates can be signed by FreeIPA's internal CA or by a third party CA that the KDC trusts. The user experience for PKUnit, you can do it from a CLI, it's not very pleasant,
13:41
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 two factor authentication.
14:02
And Windows offers a similar experience. 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 a quick demo. Klist shows me what tickets I currently have, the answer is none.
14:23
If I Kinit as Alice, I can type Alice's pass phrase 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
14:42
talking to the FreeIPA HTTP API, now if I Klist, I can see that behind the scenes it's acquired a service ticket for one of the IPA HTTP servers. I'll just destroy those tickets now, and I'll do a PKUnit.
15:03
So if I change directory here, here I have a certificate and a key, and I'll just pre-print the cert for you, so what can we say about this cert?
15:24
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 Kinit dash x, x509 user identity,
15:46
equals file, and the certificate, and the key, and a host name, not a host name rather,
16:02
but the principal name, host slash rail78.ipa.test, and Klist, here we have our TGT for the host principal. So PKUnit advantages, no more passwords or client shared secrets, the keys can reside
16:21
on the smart cards, so for example in a YubiKey, in a TPM or in a 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 x509 PKI, this brings in the renewal considerations
16:45
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.
17:02
So in the RFC, that's RFC4556 it says, the KDC must also check that the client's name is specified in the authentication service request, and it goes on to suggest how you can do that.
17:22
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
17:43
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 RFC822 name, which is an email address, pull that out, use it to look up a user principal.
18:06
And you better not mess this up, which brings us to the CVE. If we have a look at the certificate that I used to get this host principal, server.pen,
18:26
we'll see something interesting, it doesn't actually mention that principal name anywhere, the RHEL78-0, but it does have a subject alternative name, it has two in fact, one of them is a wildcard DNS name.
18:43
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
19:00
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 certmap rule is just pulling the DNS name out of the
19:20
certificate and concatenating it directly into the LDAP filter without sanitisation, 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 RHEL.
19:40
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 manage to request an email alias such as this, and
20:05
the system approved it, and you've got a certificate with that email address on it, and you have a certmap rule that looks something like this, where you're stuffing the subject RFC822 name into the query and using it to look up a mail attribute,
20:23
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
20:42
time, I think, how much? Five minutes left? So I'm going to skip it. Sorry, I'll tell you, I'll just do it. But let me discuss now the mitigations. So yes, if you're running
21:02
a vulnerable version of SSSD, you should update it. The AND list rules are harder to exploit than OR lists, just by nature, how the LDAP filter expressions work. The OR list, if you have a single sub-expression, then the whole list expression will match,
21:24
but an AND list, you have to match every sub-clause, so it's just easier to exploit an OR 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
21:42
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 PKUnit, and this first point is for just all software always, probably escape and sanitise your inputs according to how you're using them.
22:06
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
22:20
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
22:42
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 PKUnit security and PKI application security in general, it
23:02
is as critically important as validating a 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
23:24
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'll do the domain takeover demo in a minute.
23:48
Maybe we have time for one question, so is there anyone with a question that will be answered in one minute? They want the demo. Okay, so let's, I need to just change the
24:06
cert map rules, which ones are active, if I can authenticate, okay, so, IPA cert map rule find, this is just the set up, so I need to disable cert map 2 and enable
24:30
cert map 1. Okay, so this is the rule that I'm enabling. I didn't enable it. Okay,
24:55
now it's enabled, and I can do Kinit, let's see, it'll be there in the scroll
25:07
back somewhere. That's okay. So the naughty certificate and the naughty key, and I want
25:24
to be admin, and now I'm admin, and I'll show you the certificate. Okay, so this
25:41
certificate was issued to Alice, and the subject alt name includes Alice's malicious email alias. Okay, there you have it.