Linux PrivEsc: Techniques for Gaining Root Access on Servers

Privilege escalation is rarely a straight line; it is a process of meticulous enumeration and puzzle-solving. Once a low-privileged shell is obtained, an attacker must map the environment to find misconfigurations, vulnerable software, or stored secrets.

The core methodology involves:

1. System Enumeration: Gathering information about the OS version, kernel, running processes, and installed software.
2. User and Permission Enumeration: Understanding who else is on the system, what groups the current user belongs to, and identifying files with weak permissions.
3. Exploitation: Leveraging the discovered weaknesses to execute code as a higher-privileged user.

Automated scripts like LinPEAS or LSE (Linux Smart Enumeration) are heavily relied upon during the enumeration phase to rapidly identify potential attack vectors.

The sudo command is designed to allow standard users to execute specific commands as root. However, misconfigured /etc/sudoers files are arguably the most common vector for privilege escalation.

Permissive Sudo Directives

Administrators sometimes grant overly broad sudo permissions for convenience. If an attacker runs sudo -l and discovers they can run a command like sudo /usr/bin/find or sudo /usr/bin/awk without a password, the system is compromised.

Many standard Linux binaries have features that allow executing external commands. For example, if the user can run find via sudo, they can use its -exec parameter to spawn a root shell: sudo find . -exec /bin/sh \; -quit

Sites like GTFOBins provide a comprehensive, curated list of Unix binaries that can be exploited to bypass local security restrictions when executed with sudo rights.

LD_PRELOAD and Sudo

If the sudoers file is configured with the env_keep += LD_PRELOAD directive, the system is highly vulnerable. The LD_PRELOAD environment variable allows a user to specify a shared library (.so file) that will be loaded before any other library when a program is executed. An attacker can write a simple C script that spawns a root shell, compile it as a shared library, and execute any trivial command allowed by sudo (e.g., sudo /bin/ls) while injecting their malicious library. The library executes under the context of sudo (root), granting an immediate root shell.

SUID (Set Owner User ID) and SGID (Set Owner Group ID) are special file permissions in Linux. When an executable file has the SUID bit set, it runs with the privileges of the file's owner, regardless of who executes it. This is necessary for commands like passwd, which need root access to modify /etc/shadow, but are executed by standard users.

Vulnerable Custom Binaries

Attackers search the file system for these binaries using commands like: find / -perm -4000 -type f 2>/dev/null

While standard system SUID binaries are usually secure, administrators sometimes create custom backup scripts or utility programs, compile them, and apply the SUID bit to make them work. If these custom SUID binaries are poorly written—for instance, if they suffer from buffer overflows, do not sanitize user input, or use relative paths for executing other commands—they can be easily exploited to drop the attacker into a root shell.

If the server is running an outdated operating system, attackers may leverage kernel exploits. The kernel runs with the highest possible privileges (Ring 0). A vulnerability in the kernel itself allows an attacker to manipulate memory and directly elevate their process privileges to root.

Infamous examples include the "Dirty COW" (CVE-2016-5195) vulnerability, which exploited a race condition in how the kernel handled copy-on-write memory mappings, or "Dirty Pipe" (CVE-2022-0847), which allowed unprivileged users to overwrite data in read-only files (like /etc/passwd).

While kernel exploits are powerful, they are often considered a "noisy" and risky option by sophisticated Red Teams. They can cause system instability or kernel panics (crashing the server), alerting administrators to the attack. They are usually employed only when misconfiguration exploits fail.

Cron is a time-based job scheduler in Linux. The root user often uses cron jobs to automate system maintenance, backups, or log rotations. If these jobs are configured insecurely, they provide a reliable path to root.

Weak File Permissions

If a cron job running as root executes a script located in a directory where the low-privileged attacker has write access, or if the script file itself is world-writable, the escalation is trivial. The attacker simply modifies the script, injecting a reverse shell payload. The next time cron executes the job, the attacker's payload executes as root.

Wildcard Injection

Sometimes cron jobs use wildcards in shell commands, such as tar -czf backup.tar.gz * executed in a specific directory. If the attacker has write access to that directory, they can create files with specific names (like --checkpoint=1 and --checkpoint-action=exec=sh shell.sh). When the tar command expands the wildcard *, it interprets those filenames as command-line arguments, executing the attacker's script as root.

Often, the simplest PrivEsc vector doesn't require complex exploitation at all; it relies on administrative negligence.

Configuration Files and History

Attackers scour the file system for cleartext credentials. They look in application configuration files (e.g., WordPress wp-config.php, database connection strings), hidden .bash_history files where an administrator might have accidentally typed a password on the command line, or .git repositories left exposed on the server.

Reusing Passwords

If an attacker finds a database password or an API key, they will try using that same password to su to the root account or SSH into other machines. Password reuse remains one of the most common reasons privilege escalation attempts succeed.

Unprotected SSH Keys

If the attacker compromises a developer's user account, they will check the ~/.ssh/ directory. If the developer's private SSH key is stored without a passphrase and has access to the root account on the same server or other critical infrastructure, the attacker can seamlessly pivot and escalate.