Kenobi - TryHackMe Room Walkthrough
The link for this lab is located here: https://tryhackme.com/room/kenobi
In this room, we will walkthrough exploiting a Linux machine and enumerate Samba for shares, manipulate a vulnerable version of proftpd and escalate your privileges with path variable manipulation.
Full Walkthrough
The first step is to perform an nmap scan. For me, the first scan I perform is an all ports scan of each port to see which ports are actually open. The nmap syntax for this type of scan is:
nmap -Pn -p- 10.10.79.219 -oN portscan
Where:
-Pn does not ping the host before scanning
-p- specifies all ports
-oN portscan outputs to a file called portscan
This scan reveals various ports open including FTP, SSH, HTTP, SMB and NFS. The next step is to then gather more information about each ports including possible versions and OS detection. To do this, I use the following syntax:
nmap -Pn -T4 -A -p21,22,80,111,139,445,2049,32933,34781,36067,49421 10.10.79.219 -oN servicescan
Where:
-Pn skips pinging the host
-T4 specifies the speed
-A performs service detection, OS detection and some basic scripts
-p[numbers] specifies the ports found earlier (saves scanning all ports)
-oN servicescan outputs to a file called servicescan
This reveals much more information including versions for FTP, SSH, HTTP and much more. As we can see it is running ProFTPD 1.3.5 and Apache 2.4.18 as examples.
Knowing that this machine is running SMB, we can do some further enumeration specific to SMB using a couple of Nmap scripts. These scripts will enumerate shares and possible users as well. To use these scripts, the following syntax is specified:
nmap -p 445 --script=smb-enum-shares.nse,smb-enum,users.nse 10.10.79.219
This reveals some useful information such as the shares on the target - we can see there are 3 shares available. The interesting one to note is the “anonymous” share which actually sits in the home directory of the kenobi user and has anonymous read and write access.
To connect to these shares, we can use the “smbclient” program followed by the IP and the share we want to connect to. Trying to connect to the anonymous share without specifying a password allows us access to the share.
Listing the contents of the share reveals a log.txt file that could contain some useful information.
To download this entire share recursively (in case of any other hidden files) we can use the “smbget” command with the -R parameter followed by the share contents to download. This will download the log.txt to our local machine.
Opening the log.txt file reveals some useful logged information such as a private key being generated for kenobi to SSH in.
It also specifies below the FTP configuration running - as we can see the FTP service is actually being run as the kenobi user.
The next step is to actually mount this share. First, we can check the shares to see what we can actually mount using either nmap or showmount command. For nmap, the command would be:
nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.79.219
Or for showmount the syntax would be “showmount -e 10.10.79.219”
Either way, this shows us that the /var directory is a directory we can mount. Now that we have that information, we can save that for later. In the Nmap scan, we also saw that port 21 was open and running what looks like an outdated version of ProFTPD (version 1.3.5).
If Nmap did not identify the version, you can also check manually by connecting to the target on port 21 using netcat which will return the version in the FTP banner once connected.
Knowing the version number, we can then use searchsploit to check if there is any vulnerability for this specific version using “searchsploit proftpd 1.3.5” as the search term.
This returns back a couple of results. The most interesting one is the Command Execution which seems to have a Metasploit module we could use. However, we won’t use that exploit.
The mod_copy module implements SITE CPFR and SITE CPTO commands, which can be used to copy files/directories from one place to another on the server. Any unauthenticated client can leverage these commands to copy files from any part of the filesystem to a chosen destination.
We know that the FTP service is running as the Kenobi user (from the file on the share) and an ssh key is generated for that user.
Knowing this, we can use netcat to connect back to port 21 - the FTP server - and use the commands ourselves with the “kenobi” user privileges since FTP is running as kenobi to move the SSH key to the /var/tmp directory (it most likely has full write privileges).
We copy the /home/kenobi/.ssh/id_rsa file to the /var/tmp on the target machine. Next, we can mount the /var directory share to our local machine.
First, we create a directory inside /mnt and name it kenobi. Then, we mount the /var folder on the remote machine to the /mnt/kenobi directory on our local machine. Once mounted, listing the contents of the mount reveals a var directory.
We now have a network mount on our deployed machine. We can go to /mnt/kenobi/tmp and see an id_rsa key that we copied from the home directory.
Once located, we need to copy the id_rsa file to another directory - I choose my tryhackme directory - and simply change the permissions to 600 for it to work.
Once changed, we can simply use the “ssh -i id_rsa kenobi@10.10.79.219” command to connect using the private key.
Now that we are kenobi, we can navigate to his home directory and grab the user.txt flag
Now that we have a user, the next step is to try and gain root privileges. The first thing we can do is look for any files that have the SUID bit set using the following find command:
This reveals a lot of files - most of which have SUID set by default. However, there is one that looks out of place which is “/usr/bin/menu” which seems custom made.
Running this file reveals an interesting menu with options we can pick from
This seems interesting. Checking the strings inside the executable using the “strings” command, we see that it possibly runs a simply curl command for option 1, uname command for option 2 and ifconfig command for option 3 - this is theoretical as this is NOT the source code but just strings of text inside the compiled program.
This might be a vulnerability. If these strings are correct and the program is NOT specifying the full path to these commands, we could inject a malicious file named the same as one of these commands into the PATH so the malicious version runs before the real command.
We can try this with the first option - the curl command. First, we echo “/bin/bash” into a file called “curl” - the name of the command we are imitating. Then, we give the file executable permissions for anyone. Next, we simply prepend the /tmp directory to the PATH - meaning any command executed will check the /tmp directory for a command matching that name FIRST. Finally, we simply execute the menu command once again and choose the first option which was the curl option we replaced.
This gives us back a full working root shell. All that is left is to navigate to the /root directory and grab the root.txt flag
Thanks for reading this write-up. I hope you learned something new and good luck on your path to pro journey. I wish you all the best.
