Enumerating SUID files targeted for priv esc

Background

One of the methods hackers utilize in getting root, or escelating of their priveleges on a system of some kind, is to explot system binaries that are set to run as a user other than them, preferably with higher security clearence. These files on Unix and Linux are called “set uid” or “suid” files, if their suid bit is set. This will allow that binary to start up as whichever user owns the file, instead of the user that runs the file, as usual. This can be dangerous, because a few tools layng around the system are owned by root, with their suid bit set, so that you can perform certain actions as a user you wouldn’t normally be able to, without using sudo.

It is essential to the operating systems function sometimes, so don’t go randomly removing all suid bits! But be aware of this, and be aware that if a program that has it’s suid bit set, and is owned by root, has a vulnerability in it’s code, then a hacker can use that binary to gain root privs on the machine.

Using the find command

One of the tools that is installed on almost every Unix and Linux system that I have ever used, is called find. It is super useful for a variety of reasons, and is not necessarily a security tool, but comes in extremely handy for some security things. Here I will show you how you can list files around the system with their suid (set user id) or sgid (set group id) bits set. After you find them, you can usually read the man page and it will tell you why this file has that bit set by default.. or if it should not!

find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

A breif walkthrough of this find command (yes, they can become pretty clunky and complex):

The forward slash is your directory under which you want to recursively look.
The -type f means to search for files only (not directories or links)
The parentesis means search group.
We have -perm and it’s mask for each uid and gid.
It runs ls -l on its own output for reach file to show you the actual permissions on each.

Elaborating on this

We can also look inside .deb archives on a Debian based system (such as Ubuntu, Kali, etc), and see which files contained within each package have a suid binary that will be installed by default. If you can get your beloved sysadmin to install a legit binary that you know is vulnerable…

This took a little bit of code, modified from a much less streamlined version I dumped on GitHub long ago:

#!/bin/bash
# big house 5 cars your in charge
# comin up in the world, dont trust nobody
# look over your shoulder constantly
PKG=$(apt-cache search . | cut -f 1 -d ' ');
for i in ${PKG[@]}; do
 apt-get download $i;
dpkg -c *.deb | cut -c 4- | grep ^s | cut -f 2 -d '.' | tee -a deb_suid_root.txt
rm *.deb
done

This will take what the kids today call a “hot minute”. However, I have ran it on my Ubuntu Jammy development VPS and published the output.

Wrapping up

So hopefully you’ve found some juicy suid 0 binaries you can work on exploiting. If you are on the defensive side of this, flipping a file’s mode back to execute instead of suid is as easy as sudo chmod u-s filename (for a SUID) or sudo chmod g-s (for a SGID respectively). Go get ‘em!