TryHackMe – Kenobi Walkthrough
Introduction
This was an easy Linux box that involved gaining initial access by exploiting a vulnerability in ProFTPD to copy a user’s SSH key to a world-readable directory, grabbing it using SMB and using it to authenticate to via SSH and exploiting a vulnerable SUID binary in conjunction with PATH Environmental Variable manipulation to escalate to root.
Enumeration
The first thing to do is to run a TCP Nmap scan against the 1000 most common ports, and using the following flags:
- -sC to run default scripts
- -sV to enumerate applications versions
Since port 21, 80 and 139,445 are open, the next option would be to start enumerating Samba.
SMB Enumeration
Using the Smbclient tool to enumerate open shares, through null session:
The next step was to run a Nmap scan on s139 and 445 with all SMB enumeration scripts, to further enumerate this service.
nmap -p 139,445 -Pn –script smb-enum* 10.10.51.93
This reveals that the “anonymous” share is mapped to the “share” folder located in the home directory of the Kenobi user.
Connecting to the anonymous share using Smbclient shows a “log.txt” file:
FTP Enumeration
When performing a banner grab on port 21, this reveals the ftp application and version in use: ProFTPD 1.3.5
Looking for known vulnerabilities in this version of ProFTPD using SearchSploit – A few options come up, one of which allows to copy files to the remote server:
Reading the exploit documentation, it requires to specify a CPFR (copy from) and CPTO (copy to)
ProFTPD exploitation SSH key
Copying Kenobi’s SSH keys to the /var/tmp folder:
Mounting the /var directory of the remote host to a new “kenobi” directory – When navigating to the tmp directory the SSH key is there:
When viewing the file, it seems to have transferred across correctly:
Copying the SSH key to the main working directory, giving it the appropriate permissions and logging into the machine as the Kenobi user:
Privilege Escalation
Listing available SUID and GUID binaries with:
find / -perm -u=s -type f 2>/dev/null; find / -perm -4000 -o- -perm -2000 -o- -perm -6000
The /usr/bin/menu binary stands out as it isn’t a standard Linux binary.
When running the application, three options are available:
Using the strings against the command to check what it is actually doing:
The first option executes curl against localhost, but since the absolute path for the curl binary is not specified, this can be exploited by creating a custom “curl” binary and placing it in a location included in the environmental variable “PATH”.
Copying the /bin/sh binary to the /tmp directory and renaming it curl:
Adding the /tmp directory to the PATH variable
It is still trying to open “localhost”, which obviously does not exist:
As a workaround, a “localhost” script or binary can be created to execute a command as root. Creating a bash script that will duplicate the /bin/bash binary but assign to it SUID permissions, so that it can be executed as root:
Running the /usr/bin/menu binary again and using the first option
Once the binary has been created, root access can be gained by executing it with the -p flag.
When executing bash, If the -p option is supplied, the effective user id is not reset, meaning it can allow to execute commands as the user owning it.
Conclusion
This was a really fun and interesting box, as the exploit used wasn’t a simple remote code execution vulnerability but it involved some thinking in order to gain remote access, and the privilege escalation process was also quite good, although trivial to exploit.
