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.
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.
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
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
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.
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.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.
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.
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.