Hack Like A Jedi | Kenobi | TryHackMe

Hack Like A Jedi | Kenobi | TryHackMe

Hello World and welcome to HaXeZ, in this post we’re going to be channeling our inner Jedi and taking on the TryHackMe Kenobi room. This room requires you to perform some enumeration to identify services. Then, you need to enumerate SAMBA, NFS, and FTP. Next, you need to exploit a vulnerability in FTP to steal Kenobi’s private key and SSH to the server. Once on the server as Kenobi, you can escalate your privileges to root via a SUID file that uses unquoted paths.  

Kenobi Enumeration

First, I ran a Nmap scan with the safe scripts, service version, and operating system detection flags set. This revealed that there were 7 ports listening on the host. As can be seen, the important services found were FTP, SSH, HTTP, NFS, and Samba.

sudo nmap -sC -sV -O 10.10.182.106 -T4
Kenobi Nmap Scan
Kenobi Nmap Scan

Kenobi SAMBA Enumeration

Once the Nmap scan was complete, I enumerated the SAMBA shares. There are several Nmap scripts that can enumerate Samba shares, as seen in the image below. In short, the scripts used were ‘smb-enum-shares’ and ‘smb-enum-users’. As can be seen, it was possible to identify a total of 3 shares on the host. Furthermore, the IPC$ and Anonymous shares had read and write access.

sudo nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse 10.10.182.106
Kenobi SAMBA Enumeration
Kenobi SAMBA Enumeration

Accessing SAMBA Shares

Using a tool called smbclient, it was possible to access the SAMBA shares and view the files. As a result, the Anonymous share (mapped to C:\home\kenobi\share) had a file called log.txt. I downloaded that file using the get command and opened a new tab to read the contents. Notably, the log file mentioned an SSH key being generated as well as the ProftpD service running on port 21.

Kenobi Log.txt
Kenobi Log.txt

Kenobi NFS Enumeration

After reviewing the results of the Nmap scan from earlier, I noticed that NFS was open on ports 111 and 2049. NFS is short for Network File System and is another way to share directories and files on the network. With this in mind, I enumerated the NFS service using a number of Nmap scripts. As can be seen below, the NFS share was exposing the /var directory.

sudo nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.182.106
Kenobi NFS Enumeration
Kenobi NFS Enumeration

Finding Vulnerabilities With Searchsploit

It’s time to start looking for a way to gain access to the machine. From our Nmap scan, we know that we have access to the /var NFS share. We also know that FTP is running and that at some point an SSH key was created. I used Searchsploit to look for vulnerabilities in the ProFTPD 1.3.5 service. The results indicate that there is a command execution vulnerability in this version of ProFTPD.

sudo searchsploit ProFTPD 1.3.5
Searchsploit

Exploiting FTP

Ordinarily, FTP will only grant us access to the directories and files in the directory specified in the FTP configuration file. However, as this version of FTP is vulnerable and is running as the Kenobi user, we can leverage that. We can copy the SSH key mentioned in the log file, and move it to a directory that we can access such as the NFS share /var. To do this we use the ‘SITE CPFR’ and ‘SITE CPTO’ commands as shown below.

nc 10.10.182.106 21
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/tmp/id_rsa
Coping the Kenobi SSH Key
Coping the Kenobi SSH Key

Stealing The SSH Key From NFS

Now that the SSH key is on the /var NFS share, we can mount that share and steal the key. In order to do this, we’re going to use the mount command. First, we need to make a directory to mount the NFS share to. I created a directory in ‘/mnt’ called kenobi2. Next, I mounted the ‘/var’ directory to that newly created directory and stole the SSH key.

sudo mkdir /mnt/kenobi2
sudo mount 10.10.182.106:/var /mnt/kenobi2
sudo cp /mnt/kenobi2/tmp/id_rsa ~/id_rsa
Mounting NFS and Stealing The Key
Mounting NFS and Stealing The Key

Kenobi Foothold

Now that we have Kenobi’s SSH private key we should be able to access the machine. First we need to change the permissions on the key to 600 to please the SSH gods. Once that is done we can SSH to the box using the SSH key which will grant us our foothold into the machine.

SSH To Box
SSH To Box

System Enumeration

Before we elevate our privileges to root and own the entire system, we need to find a way to do so. One common method of privilege escalation on the Linux system is via programs with the sticky bit set. The sticky bit means that the program retains root privileges when run by a normal user. There is more to it but I won’t explain the details in this write-up. So, we need to find all the files with the sticky bit set. The screenshot below shows the results of a find command used to find sticky bits. Essentially, it is looking for all files where the permissions have the sticky bit and then sending errors to ‘/dev/null’.

find / -perm -u=s -type f 2>/dev/null
Finding Sticky Bits on Kenobi
Finding Sticky Bits on Kenobi
Sticky Bit On Menu
Sticky Bit On Menu

Poking The Program

If you run the same command on your local system, you will notice that the ‘/usr/bin/menu’ binary is uncommon. Running this binary shows us that the program is indeed a bespoke program and it gives us three options.

Running /usr/bin/menu Binary
Running /usr/bin/menu Binary

If we run strings against that binary, we can get an idea of what’s going on. Furthermore, we can see how the creator of this binary made a crucial mistake. We can see that the three options correspond to three system binaries (curl, uname, and ifconfig). Unfortunately for the creator, but fortunately for us, they forgot to include the full path to the binary. As this is running with the sticky bit set we can modify our ‘$PATH’ environmental variable and create our own malicious versions of these binaries.

Strings on /usr/bin/menu Binary

Kenobi Privilege Escalation

First, I changed my directory to ‘/tmp’. Then I echoed the contents of the ‘/bin/sh’ binary into a file called curl. This will be our replacement malicious binary. I then gave the newly created curl binary, read, write, and execute privileges. Finally, I exported the ‘/tmp’ path in to our ‘$PATH’ environmental variable. Now, when we run the ‘/usr/bin/menu’ binary, it will look for the binaries in the ‘/tmp’ path first. And what will it find? our malicious curl binary.

cd /tmp
echo /bin/sh > curl
chmod 777 curl
export PATH=/tmp:$PATH
Creating curl binary and change path
Creating curl binary and change path

Now, when we run the ‘/usr/bin/menu’ binary and select the status check options, it runs our malicious curl binary as root and spawns a shell with root privileges.

Unlimited Power
Unlimited Power

Conclusions

This box was a lot of fun, I’m sure there was more to it that I didn’t explore. For example, there was a web server that I didn’t even look at. With the finale of the Kenobi series being released, I thought there was no better time to do a walkthrough of this box. Try and cash in on those delicious keywords. There was nothing out of the ordinary on this box, very typical enumeration and exploitation but it was still a fun box. Anyway, I hope you enjoyed the write-up, feel free to watch the video below.

Leave a Reply