SUID:-

Set User ID is a type of permission that allows users to execute a file with the permissions of a specified user. Those files which have SUID permissions run with higher privileges. Assume we are accessing the target system as a non-root user and we found SUID bit enabled binaries, then those file/program/command can run with root privileges.

How to set SUID ?

You can change the permission of any file either using the “Numerical” method or “Symbolic” method. As result, it will replace x from s as shown in the below image which denotes especial execution permission with the higher privilege to a particular file/command. Since we are enabling SUID for Owner (user) therefore bit 4 or symbol s will be added before read/write/execution operation.

Each file or directory has three basic permission types:

read – The Read permission refers to a user’s capability to read the contents of the file.
write – The Write permissions refer to a user’s capability to write or modify a file or directory.
execute – The Execute permission affects a user’s capability to execute a file or view the contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions in your favorite GUI File Manager (which I will not cover here) or by reviewing the output of the “ls -l” command while in the terminal and while working in the directory which contains the file or folder.

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

User rights/Permissions
1. The first character that I marked with an underscore is the special permission flag that can vary.
2. The following set of three characters (rwx) is for the owner permissions.
3. The second set of three characters (rwx) is for the Group permissions.
4. The third set of three characters (rwx) is for the All Users permissions.
Following that grouping since the integer/number displays the number of hardlinks to the file.

How to get SUID files ?

By using the following command you can enumerate all binaries having SUID permissions:

1
find / -perm -u=s -type f 2>/dev/null

/denotes start from the top (root) of the file system and find every directory
-perm denotes search for the permissions that follow
-u=s-denotes look for files that are owned by the root user
-type-states the type of file we are looking for
f denotes a regular file, not the directories or special files
2 denotes to the second file descriptor of the process, i.e. stderr (standard error)
> means redirection
/dev/null is a special filesystem object that throws away everything written into it.

Unix applications use shared object libraries (.so files) to provide functionality to applications without having to re-write the same code multiple times. These shared object files are loaded into processes that are already running. They are very similar to a .DLL (Dynamic Link Library) for Windows applications. These shared object files are usually found in the /lib/ or /usr/lib/ directories.

When a program tries to call an .so file and the shared object file doesn’t exist, an error will occur. Since the program is attempting to load a missing .so file, we can create our own malicious .so file and place it in the location the program expects it to be (if we have write access to the location). Now when the program is started, it will load in our malicious .so file and execute whatever commands we want with the permissions the program is running as.

user@target$ find / -type f -perm -u=s 2>/dev/null | xargs ls -l

-rwsr-xr-x 1 root root 30112 Jul 12 2016 /bin/fusermount

-rwsr-xr-x 1 root root 34812 May 16 2018 /bin/mount

-rwsr-xr-x 1 root root 157424 Jan 28 2017 /bin/ntfs

-rwsr-xr-x 1 root root 38932 May 7 2014 /bin/ping

-rwsr-xr-x 1 root root 43316 May 7 2014 /bin/ping6

-rwsr-xr-x 1 root root 38900 May 17 2017 /bin/su

-rwsr-xr-x 1 root root 26492 May 16 2018 /bin/umount

-rwsr-xr-x 1 root root 48264 May 17 2017 /usr/bin/chfn

-rwsr-xr-x 1 root root 39560 May 17 2017 /usr/bin/chsh

-rwsr-xr-x 1 root root 78012 May 17 2017 /usr/bin/gpasswd

-rwsr-sr-x 1 root root 7376 Nov 18 22:03 /usr/bin/vulnsuid

user@target$ strace /usr/bin/vulnsuid 2>&1 | grep -i -E "open|access|no such file"

... snip ...

open("/home/user/custom.so", O_RDONLY) = -1 ENOENT (No such file or directory)

... snip ...

Other SUID File Permission Vulnerabilities:

There are a few other known attacks against misconfigured SUID binaries such as Environment Variable manipulation, and SUID binary Symlink abuse. Attacks against these vulnerabilities are far and few and usually have custom exploits which can be found on www.exploit-db.com. Like mentioned above, you can first identify SUID binaries that aren’t native to the system, and google known vulnerabilities for them. Some of the concepts behind these attacks are a little too advanced for the scope of this post and require disassembly of binaries to analyze them. I hope by mentioning them here it will give the more advanced readers something to look into, and for everyone else, just realize you can generally find known exploits for specific SUID binaries online.