🥇I am root. Let's dive into privilege escalation in OS Linux

I spent the first quarter of 2020 preparing for the OSCP exam. Searching for information on Google and making numerous 'blind' attempts took up all my free time. It turned out to be particularly challenging to understand privilege escalation mechanisms. The PWK course dedicates significant attention to this topic, but there is always a shortage of methodological materials. There are countless manuals online with useful commands, but I'm not a fan of blindly following recommendations without understanding the outcomes.

I want to share with you what I learned during my preparation and successful passing of the exam (including occasional forays into Hack The Box). I felt an overwhelming sense of gratitude for every piece of information that helped me navigate the Try Harder journey more consciously; now it’s my time to give back to the community.

I want to provide you with a manual on privilege escalation in OS Linux, which includes an analysis of the most common vectors and related tricks that you will definitely find useful. Often, the mechanisms for privilege escalation are quite straightforward, but difficulties arise in structuring and analyzing information. Therefore, I decided to start with an 'overview tour' and then address each vector in a separate article. I hope to save you some time in learning the topic.

So, why is privilege escalation even possible in 2020, if the methods have been well known for a long time? In reality, with proper user interaction with the system, it is indeed impossible to elevate privileges. The primary global issue that creates such possibilities lies in insecure configuration. The existence of outdated software versions containing vulnerabilities is also a specific case of insecure configuration.

Privilege escalation through insecure configuration

First of all, let's clarify the issue of insecure configuration. Let’s start with the fact that IT specialists often rely on manuals and resources like Stack Overflow, many of which contain unsafe commands and configurations. A vivid example is a news item the fact that the most copied code from Stack Overflow contained an error. An experienced admin would spot the bug, but that's in an ideal world. Even skilled professionals under increased workload are capable of making mistakes. Imagine that the admin is preparing and coordinating documentation for the next tender, while simultaneously delving into a new technology that is set to be implemented next quarter, all the while periodically addressing user support tasks. And then they cut him a task to quickly spin up a couple of VMs and deploy services on them. What do you think is the probability that the admin will simply overlook an error? Then specialists change, but the hacks remain, while companies always strive to minimize costs, including on IT staff.

Pseudo-shell and jailbreak

The system shell obtained during operation is often limited, especially if you acquired it through a user web server hack. For example, shell limitations may prevent the use of the sudo command, outputting an error:

sudo: no tty present and no askpass program specified

After gaining the shell, I recommend creating a full-fledged terminal, for example, using Python.

python -c 'import pty;pty.spawn("/bin/bash")'

You might ask: "Why do I need a thousand commands if I can use one, say, for transferring files?" The point is that systems can be configured differently; the current host may not have Python installed but have Perl available. The skill is to be able to perform familiar tasks in the system without the usual tools. A full list of capabilities can be found here.

A low-privileged shell can be obtained using commands 1 and commands 2 (surprisingly, even GIMP).

Viewing command history

Linux collects the history of all executed commands in the file ~/ .bash_history. If the server is actively used and its history is not cleared, there is a high probability of finding credentials in this file. Clearing history is simply inconvenient. If the administrator has to choose lengthy commands through it, of course, it is more convenient for him to call that command from history than to re-enter it. Plus, many do not know about this "hack." If alternative shells like Zsh or Fish are present in the system, they maintain their own history. To display the command history in any shell, simply type the command history.

cat ~/ .bash_history
cat ~/ .mysql_history
cat ~/ .nano_history
cat ~/ .php_history
cat ~/ .atftp_history

There is shared hosting where a server is used to host multiple websites. Usually, in such a configuration, a separate user with its own home directory and a virtual host is created for each resource. So, with improper configuration, you may find a .bash_history file in the root directory of the web resource.

Searching for passwords in the file system and attacks on adjacent systems

Configuration files of various services may be readable to your current user. They may contain credentials in plaintext — passwords for database access or adjacent services. The same password might be used for both database access and root user authentication (credential stuffing).
Sometimes, the discovered credentials belong to services on other hosts. Extending an attack on infrastructure through a compromised host is no less serious than exploiting other hosts. Adjacent systems can also be found by searching for IP addresses in the file system.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

If there is a web application on the compromised host that is accessible from the Internet, it is better to exclude its logs from the search for IP addresses. User addresses from the Internet resource are unlikely to be useful, but addresses from the internal network (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) and the sites they visit, according to the logs, may be of interest.

Sudo

The sudo command allows a user to execute a command in the context of root using their own password or even without using it. Many operations in Linux require root privileges; however, working as root is considered very poor practice. Instead, it is better to apply selective permission to execute commands in the context of root. However, many Linux tools, including standard ones like vi, can be used to gain privileges in fully legitimate ways. To find an appropriate method, I recommend checking. here.

The first thing to do after gaining access to the system is to run the command sudo -l. This will output permissions for using the sudo command. If a user without a password is obtained (for example, apache or www-data), the privilege escalation vector through sudo is unlikely. When using sudo, the system will prompt for a password. The passwd command also won't set a password, as it requires the current user's password. But if sudo is available, you essentially need to look for:

any interpreters, anyone can spawn a shell (PHP, Python, Perl);
any text editors (vim, vi, nano);
any view tools (less, more);
any filesystem manipulation capabilities (cp, mv);
tools that have access to bash, either interactively or as an executable command (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

There are many manuals on the internet that advise gathering all suid/sgid commands, however, few articles provide specifics on what to do with these programs. Options for privilege escalation that do not involve using exploits can be found here. A number of executable files also have specific vulnerabilities based on the OS version, for example.

In an ideal world, all installed packages should be checked against searchsploit. In practice, this should be done with the most popular programs like sudo. There’s also always the option to use and maintain automated tools that highlight interesting executable files with set suid/sgid bits related to privilege escalation. I will provide a list of such tools in the corresponding section of the article.

Writable scripts running under the context of Root via Cron or Init

Cron jobs can run in the context of various users, including root. If a cron job is set with a reference to an executable file, and it is writable by you, it can easily be replaced with a malicious one to execute privilege escalation. By default, cron job files are readable by any user.

ls -la /etc/cron.d  # show cron jobs

The situation is similar with init. The difference is that cron jobs run periodically, while init jobs run at system startup. Exploitation will require a system reboot, during which some services may not start (if they were not included in the auto-start).

ls -la /etc/init.d/  # show init scripts

You can also look for files that are writable by any user.

find / -perm -2 -type f 2>/dev/null # find world writable files

This method is quite well-known; experienced system administrators carefully use the chmod command. However, most guides on the internet describe setting maximum permissions. The approach of inexperienced system administrators—"as long as it works"—creates opportunities for privilege escalation. If possible, it's better to search command history for unsafe uses of chmod.

chmod +w /path 
chmod 777 /path

Gaining shell access to other users

Let's look at the list of users in /etc/passwd. Pay attention to those who have a shell. You might brute-force these users—it's likely that through one of them, you could ultimately escalate privileges.

To enhance security, I recommend always adhering to the principle of least privilege. It's also worthwhile to spend some time checking for unsafe configurations that may have remained after troubleshooting; this is the "technical debt" of a system administrator.

Custom code

It's worth taking a close look at executable files in the user's home directory and the web server's directory (/var/www/, if no other is specified). These files could be completely unsafe and might contain incredible hacks. Of course, if you have some framework in the web server directory, it makes little sense to search for zero-days within it during a pentest; however, it’s recommended to find and study custom modifications, plugins, and components.

To improve security, it's better to avoid using credentials in custom scripts whenever possible, as well as potentially dangerous functionalities, such as reading /etc/shadow or manipulating id_rsa.

Privilege escalation through exploitation of vulnerabilities

Before attempting to escalate privileges via exploitation, it's essential to understand file transfers to the target host. In addition to the usual tools like ssh, ftp, http (wget, curl), there’s a whole menagerie of possibilities.

To enhance the security of the system, regularly update it to current stable versions. versions, and also try to use distributions aimed at Enterprise. Otherwise, there are rare situations when apt upgrade makes the system inoperative.

Operating services launched in the context of the root user

Some Linux services run under the privileged user root. They can be found using the command ps aux | grep root. Such a service may not be announced publicly and be accessible locally. If it has public exploits, they can be readily applied: the failure of the service in case of failure is much less critical than the failure of the OS.

ps -aux | grep root # Linux

The most successful case is the operation of a compromised service in the context of the root user. Exploiting the SMB service provides privileged SYSTEM access in Windows systems (for example, via ms17-010). However, this is rarely encountered in Linux systems, so a lot of time can be spent on privilege escalation.

Exploitation of Linux kernel vulnerabilities

This is the path to take as a last resort. Unsuccessful exploitation can lead to system crashes, and upon reboot, some services (including those through which the initial shell was obtained) may not start. Sometimes the administrator simply forgets to run the command systemctl enable. Plus, this will cause a lot of dissatisfaction with your work if the exploitation was not agreed upon.
If you decide to use source codes from exploitdb, be sure to read the comments at the beginning of the script. Among other things, it usually states how to correctly compile the given exploit. If you're too lazy or needed it 'yesterday', you can search for repositories with already compiled exploits. for exampleHowever, one should understand that in this case, you will get a cat in a bag. On the other hand, if a programmer had understood down to the byte how the computer and the software they are using work, they wouldn't have written a single line of code in their entire life.

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Metasploit

To catch and handle a connection, it's always best to use the exploit/multi/handler module. The key is to set the correct payload, such as generic/shell/reverse_tcp or generic/shell/bind_tcp. The shell obtained in Metasploit can be upgraded to Meterpreter using the post/multi/manage/shell_to_meterpreter module. With Meterpreter, you can automate the post-exploitation process. For instance, the post/multi/recon/local_exploit_suggester module checks the platform, architecture, and necessary entities for exploitation and suggests Metasploit modules for privilege escalation on the target system. Thanks to Meterpreter, privilege escalation sometimes comes down to running the required module, but hacking without understanding what's happening under the hood isn't considered 'real' (you still have to write a report).

Tools

Local information gathering automation tools will save you a lot of effort and time, but they alone are not able to fully identify the path for privilege escalation, especially in the case of kernel vulnerabilities exploitation. Automation tools will execute all necessary commands for gathering information about the system, but it's also important to be able to analyze the collected data. I hope my article will be useful to you in this regard. Of course, there are many more tools than I will list below, but they all pretty much do the same thing — it's more a matter of taste.

Linpeas

A relatively new tool, the first commit dates back to January 2019. Currently, it’s my favorite tool. The point is that it highlights the most interesting privilege escalation vectors. Agree, it’s more convenient to receive expert assessment at that level than to sift through monolithic raw data.

LinEnum

My second favorite tool, it also collects and organizes data obtained from local enumeration.

Linux-exploit-suggester (1,2)

This exploit will analyze the system for suitable conditions for exploits. Essentially, it will perform work identical to the Metasploit local_exploit_suggester module, but will suggest links to source code on exploit-db instead of Metasploit modules.