Exploiting SUID Binaries to Get Root User Shell

In the last post, I have explained to you about the suid bit on file and demonstrated its use through the C++ program. In this post, I will use the same knowledge to exploit SUID permission misconfigurations via Labs. I will be discussing the following labs one-by-one

• Exploiting Setuid Programs
• Exploiting Setuid Programs II
• Exploiting Setuid Programs III
• Multi-User Escalation II

The following labs you can use for your practice

• https://attackdefense.com/challengedetails?cid=82
• https://attackdefense.com/challengedetails?cid=89

Let's begin...

LAB: Exploiting Setuid Programs

On checking the current directory, I found that there are two files owned by root.

Running welcome file simply prints a message.

After performing silly, yet powerful information gathering via strings command on the executable file ./welcome I found that it is calling greeting binary.

Any binary that has SUID bit set and calling another program from the PATH environment variable is a clear indication of privilege escalation. All you can do is simply prepend your path variable with the path where your malicious executable exists and it will give you a root shell.

Updating PATH won't be required as the greeting file exists in a directory owned by the student user. So you can simply perform rm -rf greetings to delete the file

Now create the "greetings" file with the following content. Once you do this, make sure to make the file executable using chmod +x ./greetings

#!/bin/bash

/bin/bash -i

Run welcome binary again

Boom, you got root shell!

LAB: Exploiting Setuid Programs II

Most of the time you will not be as lucky as in the previous lab. You need to first find the vulnerable binary and then exploit them

find / -type f -perm -4001 -exec ls -h {} \; 2> /dev/null

The above command will find the files (-type f) in the root directory (/) with having suid bit set and world executable permission set (-perm -4001) and execute ls -l (-exec ls -l {} \;) on each match. It will then redirect stderr to /dev/null (2> /dev/null) producing output that would look similar to the following image

Don't let [readonly] in vim.tiny deceive you when you open vim.tiny /etc/shadow

You are already running the process as a root user, all you need to do is create a password from the OpenSSL utility and update in /etc/shadow file

Now run change the user by executing su - root and use the same password that you have generated from the OpenSSL utility

Got the shell with the root user 😎

LAB: Exploiting Setuid Programs III

While looking for the SUID binaries, you will realize that /usr/bin/find binary outlies from other standard binaries. So, this might be used for escalating privileges

You are now experienced with the find command, for every entry we can execute a command on it using the -exec parameter. In this case, you need to use -exec /bin/bash -ip parameter to get a privileged and interactive bash shell

In case you are new to SUID exploitation and don't know how to use the command, you can check out GTFO Bins

LAB: Multi-User Escalation II

This is lab is pretty lengthy as you will have to perform horizontal privileges escalation (getting the shell of another non-privileged user) and gain access to different users and then from that user, get a privileged shell (vertical privilege escalation).

While searching for suid binaries, I found that there is a binary /userfiles/john/notebook owned by user john

On executing the binary, it spawned a shell of john user

Now again searching for suid binaries and expecting some other result. In this case, you will see /home/john/imroot is owned by the root user

On executing the program file, it didn't do anything but simply print "No root for you!!". Maybe it's expecting some arguments

The bad luck is that there exists a c program file but it is only readable to the root user.

Since GDB is installed, on debugging I first found that it is performing strlen function and comparing a string with 0x4 length. So here we get the idea that the CLI argument must be of 4 chars in length.

On further checking, iI found that it is comparing some hex strings again and again for 4 times, which is the length of our input. So lets copy it somewhere

After getting ASCII characters for \x63\x6d\x64\x3d, I found that it is equal to cmd=

When tried cmd=<command>, it is executing that as the root user. So the second command would be to spawn a privileged shell

Got privileged shell as the root user! 🥳