Link Search Menu Expand Document

Privilege Escalation in Linux

Privilege Escalation techniques on Linux usually involve some misconfiguration in the filesystem, an elevated process, or a privilege elevation mechanism that can be abused by local users to gain “root” shell on the system.

This vulnerability class is leveraged by attackers who, after gaining initial access to a server, aim to elevate their privileges, obtain full control of the system, improve persistence, and move laterally throughout the network.

Vulnerable Kernel

Kernel exploits leverage vulnerabilities in the Linux core to gain elevated privileges. This usually impacts outdated versions of Linux that are exploited by low-skilled attackers who merely download public exploits from the Internet and run them on the target. An example of this is the Dirty Cow exploit, a race condition in the kernel’s memory-management subsystem that allows local users to manipulate and then leverage privileged system files to ultimately gain “root” access. The exploit was disclosed in October 2016 and has been patched in Linux kernel versions 4.8.3, 4.7.9, 4.4.26, and newer.

Distributors promptly patch public kernel exploits, and so the risk is significantly mitigated by simply keeping the operating system up-to-date with the latest patches.

Vulnerable Services

System services and processes usually run with elevated privileges, performing a series of actions as part of their functionality, such as executing other commands, reading configuration files, writing files on the disk, loading libraries, etc. Any misconfigured or poorly designed action designed to thwart other users’ manipulation may provide an attacker with the opportunity to escalate their privileges.

The target services in a Linux system are commonly the systemd init process, the cron scheduler, and any other service that runs with higher privileges, such as web application and database services.

The security of the privileged services and processes, especially custom ones, must be carefully reviewed to avoid any abuse from malicious actors on the system. When possible, services and processes should run as their own functional user account instead of running with “root” privileges. For example, MySQL runs as the mysql user, and the Apache web server runs as the www-data user.

SUID and SGID binaries

On Linux and other Unix-derived operating systems, when the setuid or setgid bits are set for an executable file, it will run with the privileges of the owning user or group respectively. This may allow an unprivileged user to execute privileged actions; a common example is the passwd program, which must be able to both change the system password of low-privileged users and to alter the root-owned /etc/shadow file.

The list of SUID binaries available on a system must be carefully reviewed. Creating custom SUID binaries is not recommended, and their functionalities must be carefully assessed to avoid any possible abuse. A better alternative could be to specify a limited set of capabilities to custom binaries. This technique allows for more fine-grained control over root privileges granted to executables. For example, the ping program might be granted the CAP_NET_RAW capability (instead of the setuid bit), so that if an attacker managed to compromise it somewhat, they would only be able to by creating raw sockets, instead of taking over the whole server.

Sudo Settings

In Linux and other Unix-derived operating systems, the sudo program (which stands for “superuser do”) allows a permitted user to execute a command as the superuser or another user, with or without a password, as specified by the security policy. The security policies, defined in /etc/sudoers and /etc/sudoers.d, might be misconfigured or allow users to execute binaries that are not intended to be run by unprivileged users. This may allow an unprivileged user to execute privileged commands and circumvent the operating system’s separation of privileges.

The sudo rules must follow the principle of least privilege and only grant the execution of carefully reviewed commands with well-defined arguments to a selected set of users.

Weak File Permissions

Linux has inherited the concept of ownership and permissions for files from Unix. If misconfigured, permissive files may be used by unprivileged, malicious users to hijack the normal system functions and elevate their privileges. Impacts may vary from overly permissive read permissions that disclose other users’ credential files, to overly permissive write permissions that can be used to hijack services and other users’ processes to escalate the privileges on the system.

To prevent this problem, review the server’s filesystem using auditing tools capable of detecting filesystem permission misconfigurations, and then correct them as necessary.