Is this still a security problem to be concerned about?

[Spike White]

All,

https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-...


Is this a security concern for the sssd version on RHEL7 & 8?  I.e., if a
hacker acquires root on one low-value asset, can move laterally to more
high-value assets?


Spike White

[Pawel Polawski]

Hi Spike,

The KCM module mentioned in article was introduced in SSSD 1.15.3 [1]
Latest RHEL7 version is 7.9 with SSSD 1.16.5
Latest RHEL8 version is 8.3.0 with SSSD 2.3.0
Last RHEL7 version without KCM module implemented in SSSD was RHEL 7.3 with
SSSD 1.14
RHEL8 uses KCM by default, where RHEL7 is using KEYRING by default.
For more information about KCM in SSSD you can check KCM design documents
[2].

Quoting the linked article:
"With the right Kerberos tickets, it is possible to move laterally to the
rest of the Active Directory domain.
If a privileged user authenticates to a compromised Linux system (such as a
Domain Admin) and leaves
a ticket behind, it would be possible to steal that user's ticket and
obtain privileged rights in the Active Directory domain."

I would say that no matter if KCM is used or not, if the attacker has root
access to the machine which is part of the domain
this is already a security concern. Using tools described in article it is
possible to decrypt KCM disk cache and extract
access tokens. If a privileged user will authenticate on a machine
controlled by the attacker his access tokens will be stolen.
Restrictive access policies inside the domain can make reusing those stolen
tokens harder for attacker.

[1] https://sssd.io/docs/users/relnotes/notes_1_15_3
[2] https://sssd.io/docs/design_pages/kcm.html

Best regards,
Pawel

On Sat, Mar 20, 2021 at 4:06 AM Spike White <spikewhitetx(a)gmail.com&gt; wrote:

>  All,
>
>
>
> https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-...
>
>
>  Is this a security concern for the sssd version on RHEL7 & 8?  I.e., if a
>  hacker acquires root on one low-value asset, can move laterally to more
>  high-value assets?
>
>
>  Spike White
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 

Paweł Poławski

Senior Software Engineer

Red Hat <https://www.redhat.com/>

ppolawsk(a)redhat.com
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://red.ht/sig>

[Spike White]

Pawel,

Thank you for the detailed  explanation.   I know for the "Kerb-roasting"
hacking technique, if you avoid the weak KRB5 ciphers (3des-cbc,
arcfour-hmac), that thwarts this attack.

If we limit our KRB5 encryption algorithms to only strong cyphers (AES128
and AES256), would that  thwart the above SSSD attack?

Also, our KRB5 tickets expire every 10 hrs.

Spike

On Sat, Mar 20, 2021 at 6:43 PM Pawel Polawski <ppolawsk(a)redhat.com&gt; wrote:

>  Hi Spike,
>
>  The KCM module mentioned in article was introduced in SSSD 1.15.3 [1]
>  Latest RHEL7 version is 7.9 with SSSD 1.16.5
>  Latest RHEL8 version is 8.3.0 with SSSD 2.3.0
>  Last RHEL7 version without KCM module implemented in SSSD was RHEL 7.3
>  with SSSD 1.14
>  RHEL8 uses KCM by default, where RHEL7 is using KEYRING by default.
>  For more information about KCM in SSSD you can check KCM design documents
>  [2].
>
>  Quoting the linked article:
>  "With the right Kerberos tickets, it is possible to move laterally to the
>  rest of the Active Directory domain.
>  If a privileged user authenticates to a compromised Linux system (such as
>  a Domain Admin) and leaves
>  a ticket behind, it would be possible to steal that user's ticket and
>  obtain privileged rights in the Active Directory domain."
>
>  I would say that no matter if KCM is used or not, if the attacker has root
>  access to the machine which is part of the domain
>  this is already a security concern. Using tools described in article it is
>  possible to decrypt KCM disk cache and extract
>  access tokens. If a privileged user will authenticate on a machine
>  controlled by the attacker his access tokens will be stolen.
>  Restrictive access policies inside the domain can make reusing those
>  stolen tokens harder for attacker.
>
>  [1] https://sssd.io/docs/users/relnotes/notes_1_15_3
>  [2] https://sssd.io/docs/design_pages/kcm.html
>
>  Best regards,
>  Pawel
>
>  On Sat, Mar 20, 2021 at 4:06 AM Spike White <spikewhitetx(a)gmail.com&gt;
>  wrote:
>
> > All,
> >
> >
> >
> https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-...
> >
> >
> > Is this a security concern for the sssd version on RHEL7 & 8?  I.e., if a
> > hacker acquires root on one low-value asset, can move laterally to more
> > high-value assets?
> >
> >
> > Spike White
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[e-mail]...
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
>
>
>  --
>
>  Paweł Poławski
>
>  Senior Software Engineer
>
>  Red Hat <https://www.redhat.com/>
>
>  ppolawsk(a)redhat.com
>  @RedHat <https://twitter.com/redhat>   Red Hat
>  <https://www.linkedin.com/company/red-hat>  Red Hat
>  <https://www.facebook.com/RedHatInc>
>  <https://red.ht/sig>
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[James Ralston]

On Sun, Mar 21, 2021 at 4:24 PM Spike White <spikewhitetx(a)gmail.com&gt; wrote:

>  If we limit our KRB5 encryption algorithms to only strong cyphers
>  (AES128 and AES256), would that thwart the above SSSD attack? 
No.

The fundamental issue is this: if an attacker has compromised a Linux
host, then the attacker has access to any Kerberos credential on that
host, both ticket-granting tickets (TGTs) and service tickets.

This is true regardless of how/where the Kerberos credential is
cached: in a plain file (the FILE: or DIR: cache types), usually in
/tmp; in the kernel keyring (the KEYRING: cache type); or in KCM (the
KCM: cache type).

Obviously, for an attacker, some cache types are easier to extract
than others (e.g., FILE:), but if it’s on the host, the attacker has
it.  (If the credential is encrypted, then the key to decrypt it is
also on the host.)

There’s actually another cache method that isn’t well-known: if the
host accesses an NFSv4 server using RPCSEC_GSS (Kerberos)
authentication, the Linux NFSv4 kernel client code will stash the
user’s NFSv4 service ticket for the NFSv4 server in the kernel, in
order to minimize upcalls to userland to acquire the service ticket.
This means that once a user on the NFSv4 client accesses files on the
NFSv4 server, until the cached service ticket in the kernel expires,
anyone with root on the NFSv4 client can access that user’s files on
the NFSv4 server simply by using su/sudo/runas to change to the user’s
uid.  This is true even if the user ran kdestroy before logging off,
because kdestroy won’t remove the credential from the Linux NFSv4
kernel client code credential cache.  (Other than rebooting the host,
or waiting for it to expire, I know of no way to remove it.)

>  Also, our KRB5 tickets expire every 10 hrs. 
Ah, but do you enable renewable tickets?  Because if you do, if an
attacker acquires the TGT, then until the renewal expiration is
reached, the attacker can simply keep renewing the ticket.

All of this notwithstanding, using Kerberos authentication is still
better than using password authentication, where an attacker who
compromises a host can collect passwords from any users who provide
them (e.g., by using ssh with password or keyboard-interactive
authentication to get onto the host; by running kinit on the
compromised host).  And Kerberos credentials tend to expire a lot
quicker than actual passwords do.

[Sumit Bose]

On Sun, Mar 21, 2021 at 08:06:46PM -0400, James Ralston wrote:
>  On Sun, Mar 21, 2021 at 4:24 PM Spike White
> <spikewhitetx(a)gmail.com&gt; wrote:
>  
>  > If we limit our KRB5 encryption algorithms to only strong cyphers
>  > (AES128 and AES256), would that thwart the above SSSD attack?
>  
>  No.
>  
>  The fundamental issue is this: if an attacker has compromised a Linux
>  host, then the attacker has access to any Kerberos credential on that
>  host, both ticket-granting tickets (TGTs) and service tickets.
>  
>  This is true regardless of how/where the Kerberos credential is
>  cached: in a plain file (the FILE: or DIR: cache types), usually in
>  /tmp; in the kernel keyring (the KEYRING: cache type); or in KCM (the
>  KCM: cache type).
>  
>  Obviously, for an attacker, some cache types are easier to extract
>  than others (e.g., FILE:), but if it’s on the host, the attacker has
>  it.  (If the credential is encrypted, then the key to decrypt it is
>  also on the host.)
>  
>  There’s actually another cache method that isn’t well-known: if the
>  host accesses an NFSv4 server using RPCSEC_GSS (Kerberos)
>  authentication, the Linux NFSv4 kernel client code will stash the
>  user’s NFSv4 service ticket for the NFSv4 server in the kernel, in
>  order to minimize upcalls to userland to acquire the service ticket.
>  This means that once a user on the NFSv4 client accesses files on the
>  NFSv4 server, until the cached service ticket in the kernel expires,
>  anyone with root on the NFSv4 client can access that user’s files on
>  the NFSv4 server simply by using su/sudo/runas to change to the user’s
>  uid.  This is true even if the user ran kdestroy before logging off,
>  because kdestroy won’t remove the credential from the Linux NFSv4
>  kernel client code credential cache.  (Other than rebooting the host,
>  or waiting for it to expire, I know of no way to remove it.)
>  
>  > Also, our KRB5 tickets expire every 10 hrs.
>  
>  Ah, but do you enable renewable tickets?  Because if you do, if an
>  attacker acquires the TGT, then until the renewal expiration is
>  reached, the attacker can simply keep renewing the ticket.
>  
>  All of this notwithstanding, using Kerberos authentication is still
>  better than using password authentication, where an attacker who
>  compromises a host can collect passwords from any users who provide
>  them (e.g., by using ssh with password or keyboard-interactive
>  authentication to get onto the host; by running kinit on the
>  compromised host).  And Kerberos credentials tend to expire a lot
>  quicker than actual passwords do. 
Hi,

I agree with the above, if an attacker can become root on your client
you are lost. I guess it would be similar if you have Administrator
rights on a Window client.

bye,
Sumit

>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure