Privilege escalation through insecure configuration.

9 min readJun 29, 2021

First of all, let’s deal with the insecure configuration. To begin with, IT professionals often use manuals and resources like StackOverflow, many of which contain insecure commands and configs. A striking example is a news that the code most copied from StackOverflow contained an error. An experienced admin will see a loophole, but this is in an ideal world. Even competent professionals with increased workloads are capable of making mistakes. Imagine that the administrator prepares and approves the documentation for the next tender, at the same time delves into the new technology that is to be introduced in the next quarter, while periodically solving problems of user support. And then he is given a task to quickly raise a couple of virtual machines and roll out services on them. What do you think is the likelihood that the admin just won’t notice the loophole? Then the specialists change, but the crutches remain, while companies always strive to minimize costs, including for IT specialists.

After getting a stable shell

The system shell obtained during production is often limited, especially if you got it through hacking a web server user. For example, shell restrictions may prevent you from using the sudo command with error output:

sudo: no tty present and no askpass program specified

After getting the shell, it’s recommend to spawn a tty shell, Obviously some of this will depend on the system environment and installed packages, for example.

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

FAQ’s

“Why do I need a thousand commands if I can use one, for example, to transfer files?”

The fact is that systems are configured in different ways, Python may not be installed on the next host, but Perl is available. The skill is to be able to do familiar things in the system without the usual tools.

A complete list of features can be found https://gtfobins.github.io/#+shell .

A low-privileged shell can be obtained using command 1 and 2.

Viewing command history

Linux collects the history of all executed commands in the~ / .bash_history file. If the server is actively used and its history is not cleared, there is a good chance that credentials will be found in this file. To clean the history is corny inconvenient. If the administrator is forced to select ten-story commands via \, of course, it will be more convenient for him to call this command from history than to enter it again. Plus, many do not know about this “hack”. If there are alternative shells like Zsh or Fish on the system, they have their own history. To display the history of commands in any shell, just 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 sites. Usually, with this configuration, for each resource, its own user is created with a separate home directory and a virtual host. So, if the configuration is incorrect, you can find the .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 for various services can be readable by your current user. In them you can find credentials in plain text — passwords for accessing a database or related services. The same password can be used both to access the database and to authorize the root user (credential staffing).
It so happens that the credentials found belong to services on other hosts. Developing an attack on infrastructure through a compromised host is no worse than exploiting other hosts. Adjacent systems can also be found by looking up 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 directoriesgrep -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 the compromised host has a web application accessible from the Internet, it is better to exclude its logs from the search for IP addresses. The addresses of resource users from the Internet are unlikely to be useful to us, but the addresses of the internal network (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) and where they go, judging by the logs, may be of interest.

Sudo

The sudo command allows the user to execute the command in the root context with or without their own password. Many Linux operations require root privileges, but running as root is considered very bad practice. Instead, it is better to use selective permission to execute commands in the root context. However, many Linux tools, including the standard ones like vi, can be used for privilege escalation in quite legitimate ways. To find a suitable method, I recommend looking here .

The first thing to do after gaining access to the system is to run the sudo -l command. It will display the permission to use the sudo command. If a user with no password is obtained (like apache or www-data), a privilege escalation vector via sudo is unlikely. When using sudo, the system will ask for a password.

It will also not work to set a password through the passwd command, it will ask for the current user’s password. But if sudo is still available, then, in fact, you need to look for:

Any interpreters, anyone can spawn shell (PHP, Python, Perl);
Any text editors (vim, vi, nano);
Any viewers (less, more);
Any possibilities of working with the file system (cp, mv);
Tools that have output to bash, interactively or as an executable command (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid / Sgid

There are many manuals on the Internet that advice you to collect all the suid / sgid commands, but a rare article gives specifics on what to do with these programs. You can find privilege escalation options that do not take into account the use of exploits here . Also, a number of executable files have specific vulnerabilities for the OS version.

In an ideal world, you would run all installed packages through at least searchsploit. In practice, this should be done with the most popular programs like sudo. There is also always an option to use and support the development of automated tools that highlight interesting, in terms of privilege escalation, executables with the suid / sgid bits set. I will provide a list of such tools in the corresponding section of the article.

Writable scripts run by Cron or Init in the Root context

Cron tasks can run in the context of various users, including root. If a task is set in cron with a link to an executable file, and it is available to you for writing, you can easily replace it with a malicious one and perform privilege escalation. At the same time, by default, files with cron tasks are readable by any user.

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

Similar is the case with init. The difference is that tasks in cron are executed periodically, and in init — at system startup. Operation will require a system reboot, while some of the services may not be able to rise (if they were not registered in startup).

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

You can also search for files available for writing by any user.

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

The method is quite well-known, experienced system administrators use the chmod command carefully. However, in the vast majority of manuals, the setting of maximum rights is described in the vast majority of manuals. The inexperienced sysadmins ‘just-it-works’ approach creates opportunities for privilege escalation in principle. If possible, it is best to look in the command history for unsafe use of chmod.

chmod +w /path chmod 777 /path

Gaining shell access to other users

We look at the list of users in / etc / passwd. We draw attention to those who have a shell. You can cheat these users — it is possible that the resulting user will eventually be able to increase privileges.

To improve security, I recommend that you always adhere to the principle of least privilege. It also makes sense to devote time to checking unsafe configurations that may have remained after troubleshooting — this is a “technical duty” of the system administrator.

Self-written code

It is worth taking a close look at the executable files in the user’s home directory and the web server’s home directory (/ var / www /, unless otherwise specified). These files can turn out to be completely unsafe solutions and contain incredible crutches. Of course, if you have any framework in the directory of a web server, it makes no sense to look for zero-day in it as part of a pen test, however, it is recommended to find and study custom improvements, plugins and components.

To improve security, it is better to, if possible, refuse to use credentials in self-written scripts, as well as potentially dangerous functionality, for example, reading / etc / shadow or manipulating id_rsa.

Privilege escalation through exploitation of vulnerabilities

Before attempting to escalate privileges through exploitation, it is important to understand the transfer of files to the target host. In addition to the usual tools like ssh, ftp, http (wget, curl), there is a whole “zoo” of possibilities .

To improve the security of the system, update it regularly to the latest stable versions, and also try to use distributions designed for Enterprise. Otherwise, it is rare, but there are situations when an apt upgrade makes the system unusable.

Exploitation of services launched in the context of the root user

Some Linux services run as root. They can be found using the ps aux | grep root. In this case, the service may not be advertised on the Network and be available locally. If it has public exploits, they can be safely applied: a service crash in case of failure is much less critical than an OS crash.

ps -aux | grep root # Linux

The most successful case is the operation of the compromised service in the context of the root user. SMB service exploitation gives privileged SYSTEM access on Windows systems (for example, via ms17–010). However, this is not common on Linux systems, so you can spend a lot of time elevating privileges.

Exploiting Linux Kernel Vulnerabilities

This is the last way to go. Unsuccessful operation can lead to a system crash, and in the event of a reboot, some services (including those through which it was possible to get the original shell) may not rise. It happens that the administrator simply forgot to use the systemctl enable command. Plus it will cause a lot of dissatisfaction with your work if the operation has not been agreed upon.
If you decide to use the sources from exploitdb, be sure to read the comments at the beginning of the script. Among other things, it usually says how to properly compile this exploit. If you are lazy yourself or you need to have it “yesterday” in terms of time, you can search for repositories with already compiled exploits, for example however, it should be understood that in this case you will get a pig in a poke. On the other hand, if a programmer knew down to the byte how a computer works and the software it uses, he would never have written a line of code in his entire life.

cat /proc/versionuname -asearchsploit "Linux Kernel"

Metasploit

In order to catch and handle a connection, it is always best to use the exploit / multi / handler module. The main thing is to set the correct payload, for example, generic / shell / reverce_tcp or generic / shell / bind_tcp. A shell produced in Metasploit can be upgraded to Meterpreter using the post / multi / manage / shell_to_meterpreter module. With the Meterpreter, you can automate the post-exploitation process. For example, the post / multi / recon / local_exploit_suggester module checks the platform, architecture, and operational entities, and offers Metasploit modules to escalate privileges on the target system. Thanks to Meterpreter, privilege escalation sometimes comes down to launching the necessary module, but hacking without understanding what is happening under the hood is not “true” (you still have to write a report).

Tools

The tools to automate the local collection of information will save you a lot of time and effort, but by themselves they are not able to fully identify the path of privilege escalation, especially in the case of exploiting kernel vulnerabilities. Automation tools will execute all the necessary commands for you to collect information about the system, but it is also important to be able to analyse the received data. I hope my article will be useful to you in this. Of course, there are much more tools than I will give below, but they all do about the same thing — here, rather, a matter of taste.

Linpeas

Pretty fresh tool, the first commit is dated January 2019. My favourite instrument at the moment. The bottom line is that it highlights the most interesting vectors of privilege escalation. Agree, it is more convenient to get an expert opinion at this level than to parse monolithic raw data.

LinkedIn / Twitter / Medium / Email