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 |
|
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 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
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 user name 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.
