On 2/19/26 21:26, Russ Allbery wrote:
Jacob Bachmeyer <[email protected]> writes:
On 2/19/26 14:29, Russ Allbery wrote:
My understanding is that the context of this report is services running
with Kerberos credentials. [...]
That is an interesting way of looking at it. The report seemed to me to
be describing hijacking user accounts after cracking a service.
That's also possible for services that accept usernames and passwords and
validate them with Kerberos (common for POP and IMAP servers), although of
course best practices in those cases is to immediately discard the
resulting ticket after authentication.
I would that think in such a scenario, the client should be presenting a
Kerberos service ticket to the POP/IMAP server.
It is true that some methods of doing that will result in a ticket cache
stored in /tmp. For example, if the service uses PAM to validate the
user's password, some PAM Kerberos modules will write a ticket cache to
/tmp as part of that process. (There is a long and unfortunately
complicated story here why it is sometimes not possible to defer creating
the ticket cache to the PAM session stack, which generally doesn't need to
be called by servers although may be depending on how the service works.)
Such servers should take some care to clean up those temporary ticket
caches and not leave them lying around.
If PAM is creating the ticket cache when the session is opened, then PAM
should also be destroying the ticket cache when the session is closed.
Of course, one should also ideally stop using authentication methods that
send passwords over the network to a server, and lack of attention to
cleaning up ticket caches is not a Kerberos problem. It may at most be a
problem with a specific PAM implementation or service implementation.
If the server is opening PAM sessions, but never closing them, then that
is a bug in the server, not Kerberos.
I think the concern here is that the web application has its own
tickets, which necessarily must be accessible to the web application.
Therefore, if there is a vulnerability in the web application, that can
be used to exfiltrate the Kerberos tickets for the web application.
This does not necessarily give the attacker a ticket with a "~10-hour
TTL" (as claimed in the report)
Not necessarily, but it probably does. That's a very typical ticket
lifetime (I think it's the default in both MIT and Heimdal). Unless an
administrator took special precautions to limit an application's
credentials to a shorter lifetime, I would be very unsurprised by that
result.
I was thinking that it also depends on when the service last renewed its
TGT vs. when Mallory purloins the file, although Mallory could simply
wait for the service to next renew its ticket before purloining it again
and starting the "main" attack.
Fair enough: Mallory can get a maximum-lifetime TGT.
[...]
and the KDC admins should notice if the "web server" suddenly starts
asking for interactive login sessions, for example.
You are probably overestimating the sophistication of incident detection
and response capabilities at a lot of sites running Kerberos. :)
Admitted, but the "web server" also should simply not have access to
most resources.
However, a service's authentication tickets should be bound to the known
server addresses,
Binding Kerberos tickets to IP addresses was a mostly failed experiment
that, at least in my experience, most sites have abandoned. Trying to make
this work is a HUGE operational headache. In a modern networking
environment, there are innumerable reasons why the apparent IP address of
a service from the perspective of some other service doesn't match the
service's own conception of its IP address.
Across the open Internet is one thing, but I would expect (perhaps
naively) that communications between web servers and the KDC would be on
a secure internal network.
I know there are people who have gotten this to work, but I don't think
it's common. It's spectacularly annoying to try to keep configured
correctly, particularly since in a lot of compromise scenarios the
attacker has RCE anyway and can act directly from the server, so the
amount of security benefit you get from the work is debatable.
It stops the use of a stolen ticket in the report's scenario of a web
service leaking files from /tmp. :-)
[...]
There is some variation here, depending on whether the site is doing
tricky things with TGTs, but my impression was that people generally just
let all the lifetimes default to the same since the tickets are generally
all stored in the same place. If you manage to get someone's service
tickets, you generally get their TGT at the same time, so doing work to
make the service tickets less powerful doesn't have a great effort to
reward ratio.
No, this is not correct: If you have possession of the service ticket,
you can authenticate as the user to that specific service. You do not
need the TGT. Otherwise, limited ticket forwarding would not work.
Then I misremembered that detail. So the cache stores the decrypted
session key needed to use the ticket in all cases?
Yes, so far as I know. Maybe there's some new ticket cache that does some
sort of encryption, but I'm not sure what the practical benefit would be
given that the TGT is generally right there in the same file.
Aha! I did not know if the Kerberos cache stored tickets in separate
files or all together.
If they are all stored in one file, along with the session keys needed
to use them, then yes, distinctions between service tickets and TGTs are
useless: an attacker who steals a usable service ticket will also get a
usable TGT, outside of very specialized scenarios where the service
ticket endures after the TGT expires.
-- Jacob
