FunBoxEasyEnum
Introduction
This write-up details the steps taken to solve the FunBoxEasyEnum machine from Proving Grounds Play. The approach includes reconnaissance, enumeration, exploitation, and privilege escalation to gain root access.
Reconnaissance
I began with a full port scan using nmap to identify services and their versions:
Enumeration
Port 80
I begin my enumeration by targeting the web server running on port 80, which is typically used for HTTP traffic. To gather information about the target server, I use WhatWeb to identify details about the web server running on the target IP address (192.168.112.132):
From the output, I can see that the web server is running Apache, which is one of the most common web servers. The default Apache page gives me a starting point, though I haven’t uncovered anything specific yet:
The next step in my enumeration process is to search for hidden directories or files that may not be immediately visible on the website. For this, I use Gobuster, a powerful tool for brute-forcing directories. This will help me uncover any sensitive or misconfigured directories on the web server. To run Gobuster, I use the following command:
During my directory enumeration, I found a potentially interesting page: /phpmyadmin. This page is commonly used for managing MySQL databases via a web interface, and it’s often a prime target for attacks if the credentials are weak or default.
However, I don’t have credentials for this page at the moment. I tried using default credentials like root:root or admin:admin, but I didn’t have any luck accessing the interface.
While continuing with my directory enumeration using Gobuster, I came across a file named mini.php in the scan results. This file wasn’t mentioned earlier, so it’s something new I’ve uncovered during the process.
I now have an additional point of interest: the mini.php file might contain some useful functionality or vulnerabilities.
Upon further investigation of mini.php, I found that not only can I upload files, but I can also click on the uploaded files to view their contents or edit them. This opens up a new avenue for exploitation, as it means I have the ability to modify or interact with files after they’ve been uploaded to the server.
By clicking on the index.html file, I can view its contents. Since it's currently displaying the default Apache page, it is likely a simple PHP file, but it’s important to note that having the ability to read this file means I can inspect its code and understand its functionality.
I can also edit the index.html file, which is especially interesting because it gives me direct control over what the page displays to anyone visiting the site. I tried to add test string in that file
After modifying the content of the index.html file, I visited the index.html page, and I can see the changes I made displayed on the page. This confirms that my edits to the index.php file have been successfully applied and are being reflected when the page is accessed.
After reviewing the backend software, I confirmed that it’s using PHP, which means the server is capable of executing PHP code. This is a key finding because it enables me to attempt PHP code injection through the file upload functionality I discovered earlier in mini.php.
Since the server is likely to execute PHP files, I can try to upload a PHP file, such as a PHP web shell, which will allow me to remotely execute commands on the server.
Explotation
In this phase of the engagement, I successfully exploited the file upload functionality to upload a PHP web shell, granting me remote code execution (RCE) on the target server.
I uploaded a shell.cmd file with this code inside:
This code simply executes whatever command is passed via the cmd parameter in the URL and returns the output. This is a basic form of remote code execution (RCE).
I then uploaded this shell.php file using the file upload form on mini.php. The upload was successful, and I could see the file listed in the uploaded files directory.
After uploading the web shell, I accessed the shell.php file through the browser and passed a simple command (id) as a URL parameter.
With RCE confirmed, I took the next step to establish a more persistent remote connection with the target machine. To do this, I set up a listener on my local machine to wait for a reverse shell connection, and then sent the following payload to the server:
TTY Treatment
Once I had successfully established the reverse shell, the session was not as stable or user-friendly as it could be. The shell I obtained was non-interactive, meaning it didn’t allow me to perform typical interactive tasks like tab completion, command history, or using commands like sudo properly.
To resolve this, I applied a TTY treatment to the shell, making it more stable and interactive. This was done by upgrading the shell to a fully interactive terminal using the following command:
After checking the contents of the /var/www directory, I discovered the user flag.
Privilege Escalation
With user-level access obtained, the next logical step was to escalate my privileges to root or higher-level access. The system had multiple users, and I began by searching for potential credentials and weaknesses that could allow me to elevate my access.
Step 1: Searching for Credentials in .bash_history
I started by examining the .bash_history files of each user, hoping to find any stored credentials or commands that might contain sensitive information.
However, my search didn’t return any useful results, as none of the users had left any credentials or interesting commands in their shell history.
Step 2: Enumerating Running Services
Next, I enumerated the services running on the system and found that MySQL was likely running. This gave me an indication that there might be a way to leverage the MySQL service for privilege escalation.
Step 3: Searching for Database Credentials
I then searched through the system for any configuration files related to MySQL, and I found a file containing the MySQL credentials:
Inside this file, I found the MySQL username and password:
With the credentials in hand, I attempted to search the MySQL database but didn’t find anything useful at first glance.
Step 4: Cracking Password Hashes
Next, I checked the /etc/passwd file, which lists user accounts on the system. In this file, I found an interesting password hash associated with the oracle user:
I decided to attempt cracking the hash using John the Ripper, a popular password-cracking tool. After running John the Ripper, I successfully cracked the hash, revealing the password:
Although I had obtained the oracle user’s password, I didn't find any privilege escalation opportunities with this account. The oracle user did not have elevated privileges, and accessing the account did not provide any useful avenues for further exploitation or privilege escalation.
Step 5: Reusing the MySQL Credentials
While enumerating, I thought it might be worth trying the MySQL password I had found earlier for the other users. For the karla user, the password worked!
Once I successfully logged in as karla, I checked the sudo permissions and discovered that karla had unrestricted sudo access, meaning this user could execute any command with elevated privileges.
With sudo access, I was able to elevate my privileges to root by simply executing:
Last updated
