Kenobi - TryHackMe
2022-01-02

Lessons Learnt summary

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).

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.

This file looks like a log file containing some key information and some configuration data, like a Username we may assume to be an 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

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.

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.

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

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 username when trying to log in the SSH server)

We now have a remote sheel on the machine, with user kenobi's permissions, that allows access to the user.txt 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.

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.

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.

⇇ TryHackMe lessons learned