TryHackMe — Kenobi

What’s going on fellas, this is shellbreak back again with another write up about a room called knobi from TryHackMe, which is an easy room that involves a vulnerable FTP server which we’ll exploit to get user access, and then we find that there’s a SUID binary that we can abuse to get root access, so, enough talking and let’s just jump in.

As always we start off with the nmap scan:

nmap -sC -sV -oA nmap/kenobi $IP

As we see from the above picture, nmap tells us there are a bunch of open ports.

Port 21 is running ProFTPD with the version of 1.3.5 which seems a bit dated.

Using searchsploit we see that this version has a RCE vulnerability.

Let’s examine the “ProFTPd 1.3.5 — ‘mod_copy’ Remote Command Execution”

As you can see, the exploit did not work (the PoC will be discussed later in this write up).

Let’s try using the metasploit module.

Now we need to set the right parameter of this module.

Note that this exploit doesn’t have a default payload, but you can set one by listing the available payloads with show payloads and selecting the one you prefer.

In my case, I chose payload/cmd/unix/reverse_python.

Now let’s run the exploit.

And, metasploit failed to exploit the vulnerability, but considering the given error message, it appears that we don’t have write permissions on the web root directory /var/www/html .

So, at this point, it’s fair to move on to another service to enumerate.

Back to nmap results, we saw that port 445 is open and its banner tells that the service running is smb , so let’s take a look at it.

Using smbclient we can list the available shares

And we see that there’s a share called anonymous (Since anonymous login is allowed on this server, you don’t need to give any credentials to list the shares or connect to the server).

we see a text file called log.txt , we can download it with get command.

The file appears to be just a random log file, but it contains a useful information.

We see that there’s a user called kenobi on the target server, and it has a SSH key stored in /home/kenobi/.ssh/id_rsa .

But, we don’t know how to use it for now (but hey, we might be able to use it once we land a shell on the box).

Let’s head to port 2049 on which there’s a NFS service running.

You can list the available NFS shares with:

showmount -e $IP

The /var directory seems to be available to mount on the NFS server, now let’s mount it with:

mkdir nfs

mount -t nfs $IP:/var ./nfs

We mounted the share successfully but there’s not anything of interest.

So, what to do now?

Back to the ProFTPD server, and using searchsploit we saw that there’s another vulnerability.

Let’s take a look at it.

It appears to be the same vulnerability we tried to exploit before with no luck, but reading about it on google, we know that it enables the attacker to copy files on the target server. However, the issue is that using this vulnerability an attacker can write an arbitrary file and obtain a shell on the target server.

In our case, writing a file isn’t an option as we don’t have write permissions on the /var/www/html directory.

Note: nmap told us that port 80 is open and there’s an HTTP server running on it, but we won’t talk about it now because it’s not useful in our case.

Let’s do a recap of what we’ve done/found so far.

1. There’s a vulnerable FTP server that we can abuse to copy files on the target server.
2. The SMB server had a text file log.txt that tells us the user kenobi has an SSH key stored in /home/kenobi/.ssh/id_rsa .
3. The directory /var is shared on an NFS server, which we can mount on our machine.

See the attack scenario here? ;)
We will be exploiting the File Copy vulnerability on ProFTPD server to copy the user’s ssh key to /var/tmp , and then mount the /var directory to our machine to read the ssh key.

We successfully copied the ssh key into /var/tmp directory, now let’s mount the NFS share again to read the key and get a shell on the box.

And we did it :)

Now let’s ssh into the box using that key.

Note: Don’t forget to set the right permissions to the key file.

chmod 600 id_rsa

And, we got a user shell :)

Let’s move on to the root part.

As always, when I first get a shell on a box, I try sudo -l , but that didn’t work on this box, so our go-to would be looking for SUID binaries.

find / -type f -perm -u=s 2>/dev/null

From the output we see a weird SUID binary called menu . Let’s run it to see what exactly it does.

It gives us a list of 3 choices, and according to the output, it appears that it just runs regular linux command.

1. In the first option, it’s either running curl or wget to send a web request.
2. In the 2nd option, it’s running uname -r to get the kernel version of the OS.
3. And this one is pretty obvious that it’s ifconfig .

Now we need to do a pretty simple reverse engineering to understand how the program is calling the binaries mentioned above.

As ltrace and strace aren’t installed on the box, I transferred the binary to my Kali machine to examine locally.

Using ltrace to see how the program is calling the mentioned binaries,

we see, that the program is calling the binaries using relative path.

Back to our target machine

In the $PATH environment variable we see that /home/kenobi/bin is one of the directories the Operating system searches in when we call binaries using relative path, in this case, we can exploit this by doing a so-called PATH Hijacking .

Let’s move to the practical part, shall we :)

Create a new directory and name it bin , and inside the directory create a file and name it uname

Let’s re-run that SUID binary, and get our root shell (do not forget to set your nc listener to capture the reverse shell).

We chose the 2nd option as it’s the one that calls uname binary.

If you did everything as explained in this write up, you should obtain the root shell.

And here’s our root flag ;)

So, that was the box, but we’re not finished yet :)

Let’s examine the python script we used to exploit the ProFTPD, and see why it did not work.

The web server’s root directory is owned by the root user, and the user kenobi doesn’t have write permissions on it, so it’s impossible for us to be able to write a reverse shell on to the web server’s root directory, but let’s change the permissions so that the user kenobi can write files, and see how the python script is going to exploit the RCE.

Now back to our Kali machine, we will run the exploit again

Although we gave write permissions to the user, we still can’t write files on the server. After googling for a bit, I found out that the PoC is sending the payloads to the FTP server via a socket, but it’s sending them as a regular message, however, they should be sent as a data stream (not to mention that the commands were wrong), and because I love scripting with python, I decided to write my exploit for this CVE.

Now when we visit the given URL, we get a prompt to download the php file, that’s because php isn’t installed on the web server.

You can modify this script to copy the ssh key as we did manually before.

So, that was the box, I hope you guys enjoyed it, take care, and I’ll see you all in the next write up. :)