SUID / SGID abuse
Last updated
Last updated
If the file is owned by root, it gets executed with root privileges, and we may be able to use it to escalate privileges.
We can use the following find command to locate files with the SUID or SGID bits set:
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/nullor
find / -perm -2000 -o -perm -4000 2> /dev/null
after finding the binaries, check GTFOBins for them to see if any of them is vulnerable to shell escape:
why we can’t just use the same LD_PRELOAD and LD_LIBRARY_PATH environment variable tricks we used with sudo privilege escalation?
Both these environment variables get ignored when SUID files are executed
Certain programs install SUID files to aid their operation. Just as services which run as root can have vulnerabilities we can exploit for a root shell, so too can these SUID files. Exploits can be found using Searchsploit, Google, and GitHub, in the same way we find exploits for Kernels and Services.
for example we found an SUID file for exim service:
-rwsr-xr-x 1 root root 963691 May 13 2017 /usr/sbin/exim-4.84-3Exim is a popular mail transfer agent that is somewhat notorious for having many security vulnerabilities.
The version of exim is rather obvious from the filename, however we can confirm it:
$ /usr/sbin/exim-4.84-3 --versionUsing searchsploit on our local machine, we find a local privilege escalation for this exact version:
Copy the exploit script across to the target machine. You may need to remove ^M characters from the script:
sed -e "s/^M//" 39535.sh > privesc.sh
Make sure the script is executable:
chmod +x privesc.sh
Execute the script to gain a root shell:
./privesc.sh
we have a suid program that prints out a given file contents named printfile we have a password file that cant be read by this program which contains root password .it seems the program printfile outputs the text from a file; just like cat. Therefore, we can assume that it’s using cat somewhere in the code.
make a temp directory, and a new text file that we can use for testing the program with ltrace.
From the output, we can see that there is a small security hole in the way this program functions. If you look closely, you can see that the function access() and /bin/cat are being called on the input file. What access() does is check permissions based on the process’ real user ID rather than the effective user ID
And if we look back into the previous ls -la output, we can see that printfile is owned by leviathan3. So access() will call the process with leviathan3’s privileges
Looking into the code we also see that /bin/cat is being called on the file to output the contents. While access() uses the full path’s filename, /bin/cat uses just the first part of the filename. (This is due to how the “ “ are set up in the program) What we can do here is try to add a space to a filename, and if we are correct, /bin/cat will read the file as 2 separate files.
As you can see, /bin/cat calls “pass file.txt” as two separate files, “pass” and “file.txt”. We can actually exploit this! Let’s go ahead and create a symbolic link for the “pass” part in “pass file.txt”, and link it to /etc/leviathan_pass/leviathan3.
as you can see we where able to read password file.
Just as we were able to use shell escape sequences with programs running via sudo, we can do the same with SUID / SGID files. A list of programs with their shell escape sequences can be found here: Refer to the previous section on shell escape sequences for how to use them.
