This is a write-up for the “Kenobi” lab, an “easy” rated machine that is available for free at https://tryhackme.com/room/kenobi. Due to dishonesty about the use of user data, I currently do NOT recommend the use, especially paid use, of TryHackMe. However, if you decide to use the platform, this write-up may be of use for educational purposes.
This machine is available as a walkthrough-style room, but I will be demonstrating the compromise of the machine without prioritizing the answers to the guided questions. I am documenting the process I used to find all information in this write-up WITHOUT including any flags, in the spirit of the game. However, following this process exactly should result in a full compromise of the target system.
Recon, Scanning, and Enumeration #
My first step was to ping the box to ensure that it was alive and ready for enumeration:
Next, I ran a quick nmap scan to enumerate the service versions:
nmap with the -sC flag here to run some basic nmap scripts against found ports. In this case, it just made the output too long for a clean screenshot, so I’ve omitted the script output, which is not necessary for this write-up.
We see that we have FTP, SSH, an Apache web server, and several file-sharing services. We can see that the machine is running Samba, an interoperability service for using SMB on Linux servers. Since this will behave just like Windows SMB, let’s see if we are able to access any of the shares unauthenticated:
One share stands out here. Let’s check the contents:
We have what looks to be a log file, showing several items, including the creation of an RSA key pair and some assorted configuration information - a bit more on that later.
Since we have an explicit version of the FTP server, let’s see if there are any known vulnerabilities:
After striking out on some of the jucier exploits (beyond the scope of this write-up, but basically because we aren’t able to write to any of the Apache server’s paths, we can’t upload and utilize a reverse shell as the “www-data” user, which is fine because that would not allow us to access the privilege escalation portion of this lab anyway), we can see that we are able to copy files around on the filesystem.
We can use some of the information from the log file to help us weaponize this. For example, we know the username and absolute path of the private key created at the beginning of the file:
From later in the file, we also know the on-disk location of the “anonymous” share we were accessing via Samba earlier:
Combining this information, we should be able to weaponize CVE-2015-3306 to gain initial access to the machine.
Initial Access #
Now that we know our path, weaponization is pretty straightforward. We will use the vulnerable mod_copy module to move the private key to the anonymous share, then download it:
We can now attempt to use this private key to access the filesystem using SSH:
chmod 600 id_rsa) to use it with SSH.
Privilege Escalation #
Now that we have an SSH session as the “kenobi” user, we can perform some preliminary privilege escalation checks. After striking out on sudo -l, as we do not have the “kenobi” user’s password, we find a non-standard binary with SUID permissions:
Investigating the binary, we can see that it will prompt for input, then run a command (as root, because of the SUID bit!) depending on the input:
Something else to note is that this “menu” binary is running the other system binaries WITHOUT an absolute path. This opens up this binary for SUID exploitation via PATH variable manipulation (“uhm, acktually…” this isn’t technically manipulation, since the PATH variable is already (mis)configured for us. The weakness already present is therefore technically more akin to search order hijacking in Windows, but the path here on Linux is more similar to how you would exploit a writable PATH variable).
Because we are (or root is, in this case!) attempting to run a binary without its absolute path, the machine will iterate through our PATH variable, checking for a binary that matches that name in each consecutive file location in $PATH. We can check our PATH using env, or more simply, just echo the value of the PATH variable:
We now have full control over the first entry of the PATH variable, which will search “/home/kenobi/bin” before checking other directories. The manner in which we weaponize this is somewhat arbitrary, but notably, if we just write text to a file and execute the file, it will run the file as though we were running a bash script:
So all we need to do is overwrite a command of our choosing with “/bin/bash” to get a bash shell as root:
Special thanks to the room creators for making this lab!