I'm working for the 3APA development team and I'm also the maintainer for Kebras, for
Fedora, CentOS and REL.
And today I'll be talking about, well, Kebras, 3APA and the Bronzebead vulnerability.
So a few general words about Kebras.
So it's authentication protocol relying on cryptographic, symmetry cryptography.
And it's like 36 years old now.
It can be described, I guess, as a very early implementation of a single sign-on principle.
If I can run a quick poll, as who has been maintaining a service using Kebras for authentication,
here.
Okay, so a few words.
And have you heard about the Bronzebead exploit for Kebras?
No, okay.
That's actually normal because it's something from the AD world, actually.
So something that is often gets in the way of understanding things about Kebras is the
terminology, like this old vocabulary like, so, a ticket, key tab, KDC, authentication,
S-Rack, things like that.
So I made my best in this presentation to try to use as generic terms as possible so
you can really get the main idea.
So basically the three terms I'm going to use in this presentation that are specifically
to Kebras is things like ticket, key distribution center, and ticket granting ticket.
To just give you a gross idea of how Kebras works, you run authentication once against
the KDC, this is the Kebras server, basically.
It responds with a ticket, especially in this case a ticket granting ticket, so a TGT.
And then it uses this TGT to request tickets to other services, basically.
So you can authenticate in all the services in the organization.
So that's like the usual use case for Kebras, but in this talk I'll be mainly speaking about
an extension to this core part of the protocol, which is the MSS4U extension.
So it responds to a common use case that you are facing.
Let's imagine you have a web application and this application has to access some backend
services like an SQL database or a distributed storage system.
And very often you have access control happening on this backend service, so you cannot access
the user-related data that you cannot access using just the identity of the front-end service.
So you need access permission specifically to the user.
So what you want to do in practice is impersonate this user to actually access the resources
they have access to.
So the historical way we are dealing with that is that problem is by doing TGT forwarding,
which is basically just you take this TGT, so this initial ticket, you send it to the
front-end service and then this front-end service can just reuse it to request other
tickets in your name.
But the issue here is there's basically no granularity in the permission you are granting
actually granting to the front-end service because it can just request ticket to any
other service.
So it's definitely something that had to be improved.
So Microsoft actually designed this extension, so S4U.
It adds two new mechanisms to the protocol.
The first one is constraint delegation, also called S4U to proxy.
What it does basically is so you have the user, this front-end service, I'll be calling
it the proxy service and the target service like the backend, SQL database, distributed
network volumes, something like that.
And so in IPA we provide a tool to configure some delegation rules saying okay this web
application has the permission to impersonate user for this backend service.
You need specific permission to do that of course.
And so I'll be explaining that with the diagram.
So here you have three agents.
You have the user, the proxy service, so the front-end service, the target service,
and the free IPA KDC.
So and you have each of them as a key except the KDC that has the key of everyone.
So what we'll be doing when we're doing constraint delegation is first the user is going to use
the TGT to run a request against the proxy service.
Now the proxy service to process this request it has to access the target service as the
user so what it will do is run an S4U to proxy request providing both its own TGT and what's
called the evidence ticket.
So the ticket the user provided to this proxy service.
So free IPA will process the request so there is a condition for this request to succeed.
You see in a moment why we have this condition is to have one of the flag in the ticket,
the forwardable flag set to 1.
And if that's the case it's going to accept the request so send back to the proxy service
the ticket for the user to the target service and then the proxy service can reuse this
ticket to run a request as the user against this service and the request.
So it was constraint delegation.
Now the other mechanism in this extension is called the proxy transition or S4U to self.
It's meant to solve a different problem basically.
The way it's described by Microsoft is when you have a case where you have a service which
is not using K-Bros as the authentication method in front of a face by the user to authenticate.
You can use that to obtain a ticket for this user to the Flotent service.
So you can still integrate with some local services that are requiring a K-Bros ticket
to work and something like that.
And it's also a way to obtain some group membership information that are contained in the ticket.
I'll come back to that in a moment.
So how it works basically.
So it's called proxy service.
I wrote that for the courier and 3D of the diagrams but it's not necessarily proxy services
can be any service actually.
So it runs an S4U to self request for user U using its own TGT.
And then so we come back to this forwardable flag thingy.
So at this point there is an attribute of the proxy service in the 3API database and
according to the value of this attribute the forwardable flag will be set or it won't
be.
So if it's false you don't get the flag.
If it's true you get the flag sector 1 and then you send this ticket back to the service.
So that's where the Bronze bit buildability gets in.
So something you might anticipate while looking at that is if you have a service that has
the permission to request this forwardable evidence ticket and this service also has
a delegation rule with another service.
It means the service is basically able to request an evidence ticket for any user and
use it against the target service.
So that's something that is not recommended to apply usually but if you paid attention
in my previous, so I'm going to show you that.
So we have a compromised proxy service here.
It has a delegation rule to the target service.
So first it does an S42 self request.
The proxy service does not have this rule that allows it to get a forwardable evidence
ticket.
So that's what you get, a non-forwardable evidence ticket.
The issue is here you have this part in the ticket that is encrypted using the key of the
proxy service.
So actually once it's received the attacker could just decrypt this part, flip the forwardable
flag and then re-encrypt it and send it to the KDC again as a S42 proxy with this modify
evidence ticket and then the KDC will check the forwardable flag, it sets so then it's
allowed and then the attacker gets a ticket to the target service as a user.
As you can see the user it doesn't do anything in this whole process so it can do so with
just any user including a user that has administration privileges on this target service.
Yes?
I understand that the reason why the proxy service is able to change the forwardable flag
is because it's encrypted using the key of the proxy service.
But is that also the same reason why it's able to impersonate any user?
It's able to impersonate any user because there's a delegation rule between the proxy
service and the target service.
But it does not have this specific property that allows it to request a forwardable evidence
ticket.
So this should not happen normally.
If a forwardable flag was properly...
The main important thing here is for you to sell this flag.
I want the ticket to be held user to myself.
It was deemed to be innocent because it's for yourself not for anyone else.
And it's not forwardable so you cannot use it as evidence for anyone else.
The problem is that not only it can decrease that area and change anything, the area is
specifically not checked soon.
So you cannot verify that they...
Yeah, the whole problem is this area is not protected.
It's protected by the key...
I mean, it's encrypted using the key of the proxy service but that's all.
The proxy service cannot...
What I don't understand is how the proxy server in this case is able to change that
plan but you also said it's able to impersonate any user.
Because the S42 self works for any user.
It's not supposed to...
You're not supposed to get a forwardable evidence ticket for any user if you don't have this
specific permission.
So...
Time flies.
So the issue we had in the APS case, if there was just...
There are a lot of reproducers for this issue on AD but there is actually none for IPA for
multiple reasons mainly because there are...
It was mainly an issue of encryption types.
There are multiple encryption types for Keablos.
And our default encryption type basically on IPA is...
HMACSHA2 encryption types and they are not implemented by AD right now.
So that's why it was...
We had to implement a reproducer ourselves.
Actually, there's a full request here if you want to have a look.
So the solution that was designed for that by Microsoft is something called the ticket
signature.
I'll skip some details.
Basically, there are a lot of things in the Keablos tickets and there is also another extension
designed by Microsoft.
It's called MSPAC.
It stands for Privilege Attribute Certificate.
So it's another...
Basically a piece of metadata in the ticket that contains various kind of information
and it's signed by multiple keys as it's a certificate.
And what is...
For this signature, it's basically...
While it protects the encrypted part including the forwardable flag.
So that's the response to this attack because here if the attacker tries to flip the forwardable,
the flag is still possible because it's only encrypted with proxy service key.
So the flag is flipped, re-encrypted, send as an SOU to proxy request.
But here before actually checking the delegation rules, it will recompute the signature compared
with the one saved in the pack.
If it's not matching, it will just reject the request right away.
But we had an issue for CentOS and REL8 because there we are using a MATKWAS version 1.18
and this version handles generation of the pack in a completely different way.
There was a major rework in MATKWAS 1.20 and because we have some ABA compatibility rules,
we cannot just backport this full fix on the CentOS and REL8 version.
This is basically all we had in the API for KDB plugins.
So there's nothing...
We have no access to the encrypted part basically so that's why we could not implement this fix.
But the approach we took was different so if we cannot protect this flag,
maybe we can implement something to actually detect this attack when it happens.
So there are a lot of information in the pack actually including a list of security identifiers.
So it's something that is specific to the AD world but we have some support for it in IPA.
And there are especially two SIDs that are interesting in this case.
This two SID basically the first one indicates a user was pre-authenticated to use the KABLOS term
in the normal way or there's another one indicating that the evidence ticket was obtained using SOU2.
So that's actually something we can use in this case to...
So we start the same way.
So the attacker sets the forwardable flag to 1.
Then it sends the SOU2 proxy request with the modify evidence ticket.
And then what we do is...
So we do the same, we check the forwardable flag and we check the SOU2 self rule allowing to set the forwardable flag also.
And we check what's the SID indicating the way the evidence ticket was obtained.
And if we see that the SID is not matching the value of the forwardable flag then we can just say
this is actually a bronze bit attack happening so we can reject the attack the issue is...
I said the pack was like a certificate so it's supposed to be protected but it's actually not for K.
It was also compromised basically at some point.
So there was a way for an attacker to actually modify the content of the pack including the SID.
This is this CV, it's basically a pack spoofing attack.
It was based on basically how the content was signed because to give some details the initial signature is done by the proxy service key
and then this signature is signed by the KDC but the problem is since it's just signing a very small part of the pack
you can do some spoofing etc. to eventually modify the actual content of the pack.
This was fixed by Microsoft also by adding a new signature in the pack.
So this time it's called the extended KDC signature and this time the KDC uses its key to sign the full content of the pack
so it removes this vulnerability.
So now it's basically the same approach except when we reach that point we check the extended signature before
and then we do this check I mentioned earlier.
So, conclusion already.
So yeah, I thought this is an interesting, like typical example of the kind of tribulation you're facing
where you're doing long term support especially for security rated protocols
and it's also an occasion to talk about this as for your extension
because that's something that it's a good example of a gradual shift.
So, the next cabros is currently doing from the authentication only protocol to some protocol
also now providing some authorization information.
I already described that with this list of seeds but there are actually a lot of stuff
and there are plans to start using that in the future in the IPA and open source projects.
So yeah, that's all.
Okay, so I was quick about that thought.
So there are some reference interesting articles, pointers to multiple pull requests,
backpots to centers, things like that if you're interested.
Now if you have questions.
How long does it take?
Well, the patch actually it's relatively simple.
There has been some hiccups in its deployment but the main thing is that you have all this kind of dependency
like we have information we want in the pack but the issue is since this in 2022
the pack did not be considered trustworthy anymore because you can actually spoof its contents.
So first you have to backport the support for this extended caddysys in nature
to be able to actually trust the content of the pack and then you implement this actual detection method.
It took roughly a half a year to actually design the scheme on detecting traces.
It's literally detecting some evidence that is left by a hacker which is not supposed to be there
but finding what you can trust from evidence took like a half a year in overall drawing board design.
So it's not really written in code and then backport in this extended checksum took another problem
because now NIA IPA running on Kerperos 120 becomes suddenly incompatible with 118
because of the re-factors that was like checksum missing and then another authorization data is missing
and then all the walls and the wall reverberation doesn't understand.
So there's a lot of work not technical but more investigative.
You can definitely make a movie about this.
And some politics against.
And also politics of course, yeah, because we have to think also even for all the versions.
Okay, so time's up.
Thank you.