Symfonos 6 || VulnHub Walkthrough

Hello, everyone! Welcome back to our VulnHub Walkthrough series. In today’s video, we’ll continue exploring the exciting VulnHub collection with "SymfonOS." Specifically, we’re diving into the 6^th and our last virtual machine in the series, " SymfonOS 6 ." This intermediate, OSCP-like, real-world scenario machine is designed to highlight the importance of understanding vulnerabilities and how to exploit them effectively. 

Let’s get started!

To begin, head over to the VulnHub website and download the machine's image file. If you're new to VulnHub, check out our playlist for helpful guides on how to use the platform. 

Now, let’s get started with exploiting this machine!

Settings Up

Previously, we downloaded all the 6 image files. 

So, our next step is, to set up the Virtual image in VirtualBox. The downloaded image file is in the form of 7Z format, so start by extracting the archive to access the files within. You’ll find several files, including the essential VMDK files, in the extracted folder.

Now, our next step involves “ creating a new virtual machine ”.

Creating a New VM

In VirtualBox, click "New" to create a new VM. 

Name it " SymfonOS 6 ," set the OS type to Linux, and choose " Other Linux 64-bit " for the version since the specific distribution is unknown.

Now, allocate the desired amount of  RAM . 

Next, select " Use an existing virtual hard disk file " locate the VMDK file, and click on " Finish " to complete the setup. 

Once the setup is finished, you'll see the " SymfonOS 6 " vulnerable machine in the  VirtualBox manager . For better organization, let me regroup it into the VulnHub group.

Network Configuration

To ensure that both your  Kali Linux machine (used for attacks) and  the vulnerable machine are connected to the same network, do we have to make sure they're both connected via a  host-only Adapter ? 

So, go to “ settings ” and change the Network adapter to " Host-Only ." 

Since everything is ready, let’s attempt to start the VM to check if it works.

Start the VMs

Once it's ready, you should see a  login prompt , indicating that everything is set up and we can begin our exploration!

Finally, notice that our vulnerable machine is ready, with a login prompt awaiting. Let's dive into the fun!

                                                                                                             

Enumeration

Identify the IP address

The first step in our attack is enumeration, where we identify the IP address of our target machine using the netdiscover tool. This step helps map the network and locate devices that are up and accessible.

To execute this, open a terminal and enter: netdiscover –i <specify Network Interface name> , which in this case is eth1. 

The command output displays a list of devices detected on the network, showing their IP and MAC addresses, as well as the associated vendor.

From these results, we can see several IP addresses along with their corresponding MAC addresses. Our target machine’s IP address is identified as “ 192.168.103.18” .

Mapping the Network

Next, we'll perform a network scan to identify open ports on the target, which is a critical part of the enumeration process. Identifying open ports provides insights into the network’s attack surface, helping us pinpoint services that may be vulnerable to exploitation. For this task, we’ll use the popular network scanning tool, Nmap.

To execute the scan, open a terminal and run the command:

In this command:

• -sC : Performs a script scan using Nmap's default scripts to gather additional information about services and identify potential vulnerabilities.
• -sV : Enables version detection to determine the versions of services running on open ports.

After the scan is completed, the results reveal four open ports with their respective services:

• Port 22 (TCP): Running SSH (Secure Shell), which allows remote access with valid credentials. Although generally secure, weak or default passwords could make it vulnerable.
• Port 80 (TCP): Running HTTP on a web server. The scan shows a basic website with no title hosted on Apache HTTPD, which may contain web-based vulnerabilities.
• Port 3000 (TCP) : Running a service resembling Gitea, a self-hosted Git service. Potential vulnerabilities include weak or default credentials, unpatched security flaws in outdated versions, or exposed sensitive APIs.
• Port 3306 (TCP) : Running MariaDB, a database service. Unauthorized access is disabled, but vulnerabilities may include brute-force attacks on credentials, outdated software versions, or misconfigured permissions.
• Port 5000 (TCP) : Hosting a minimal web service that returns HTTP errors such as "404 Not Found." Potential risks include exposed endpoints , misconfigurations , or exploitable vulnerabilities in web service logic.

These open ports may present potential entry points into the target system. The next step is to conduct a deeper enumeration of each service to uncover vulnerabilities or clues that could facilitate initial access or shell exploitation. This analysis will guide the development of a strategic approach to compromise the target.

Web Enumeration

Our next steps focus on identifying vulnerabilities to gain shell access or another foothold on the target system. The HTTP web server, running on Port 80, will be our starting point, as web services are often key entry points and can uncover additional attack vectors.

Begin by accessing the web service by entering the target's IP address into a web browser. 

The displayed webpage features an image depicting a Greek mythology scene, likely referencing the Trojan War or a similar legendary battle.

Inspecting the page source using CTRL + U does not reveal any hidden information. 

Web Directory Enumeration

To discover hidden resources, we will perform directory enumeration using tools like dirb or Gobuster , which scan for accessible directories or files not immediately visible in the web interface.

These tools systematically scan for common directories and file names that may not be directly visible on the website, potentially revealing sensitive files or directories that could aid in further exploitation. 

Execute the appropriate commands in the terminal to initiate the enumeration process.

The results of directory enumeration typically highlight potentially sensitive or hidden files and directories on the web server. Each file or directory's HTTP response code and status provide critical insights into access restrictions and potential security risks.

• The index.html file , with a 200 OK status, confirms it is accessible and serves as the homepage—already viewed in our initial browser access.
• Directories like flyspray/ and posts/ , returning 301 Moved Permanently , suggest redirections to other locations. These might lead to hidden web applications, management interfaces, or repositories, warranting further exploration.

To gather more information, let’s explore these paths in a browser. 

Visiting the /posts webpage reveals a custom blog featuring the following description:

“ The warrior Achilles is one of the great heroes of Greek mythology. According to legend, Achilles was extraordinarily strong, courageous, and loyal, but he had one vulnerability Achilles heel. Homer's epic poem The Iliad tells the story of his adventures during the last year of the Trojan War. ”

At first glance, this content does not provide direct clues. However, when compared to the homepage, it appears to be a textual description of the image displayed there. This connection may hold significance, so further analysis of the content and its context is recommended.

Inspecting the FlySpray web Dashboard

Now, let’s inspect the flyspray/ webpage. 

Upon visiting, it is identified as the web interface of Flyspray, a task-tracking system . 

The presence of Flyspray often suggests a potential avenue for exploitation, as outdated versions may have known vulnerabilities. 

Before diving deeper, we need to enumerate the Flyspray interface for useful details.

In below,the webpage displays three main tabs:

• Task List
• Overview
• Roadmap

This Task list tab shows a single task with the following details:

• Category: Backend / Core.
• Task Type: Bug Report.
• Priority and Severity: Very Low.
• Summary: Bug report.
• Status: New

Clicking on the task provides additional details, which could be useful. 

In the comment section below, there is a comment posted by "Mr. Super User" , which might provide further clues.

About the other 2 tabs:

In the overview , This tab shows general information about the system, including a summary of Symfonos bugs , with two open tasks listed.

The Roadmap section appears empty, showing no information about future plans or tasks.

Also, there is a Login button visible in the top-right corner, indicating the possibility of accessing administrative or advanced features. 

Clicking on it opens a login form requiring a username and password, along with an option to register a new account.

At the bottom-right corner of the interface, the text "Powered by Flyspray" is displayed. 

This information is crucial for fingerprinting the exact version of Flyspray, which can help identify any known vulnerabilities associated with the software.

Exploitation

Looking for Potential Vulnerabilities

Although the specific version of Flyspray is not directly exposed on the interface, a quick search on ExploitDB reveals potential vulnerabilities. Using the command: 

Among these search results, the exploit listed in the sixth position , targeting Flyspray versions 1.0-rc4 , might be valuable. This exploit could potentially allow us to take advantage of known vulnerabilities within the application.

Exploiting FlySpray (Manually)

So, let's download this exploit to local storage. 

Now that it is saved as a text file, let's open it and examine its contents. 

The file provides basic information about the exploit, outlining its purpose and potential impact. Let's analyze it further.

SSRF (Server-Side Request Forgery) vulnerabilities allow attackers to send crafted requests from a compromised server, potentially accessing internal systems or escalating the attack. In this case, an XSS (Cross-Site Scripting) vulnerability in Flyspray 1.0-rc4 can be combined with CSRF (Cross-Site Request Forgery) to exploit the system further. This approach could create a new admin account by leveraging the XSS-to-CSRF method.

Upon reviewing the file, I can determine how it can be utilized. 

Register a New user and verify if is it Vulnerable to XSS

To test for an XSS vulnerability, our first step is to register a new user .

1. On the login page , click on the Register button. 

2. This action displays a registration form that we need to fill out.

• In the Username field, enter a username of your choice.
• In the Password field, input a password. For this demonstration, I'll use 12345678.
• In the Real Name field , I will insert a basic XSS script that triggers an alert displaying "hello" upon successful execution.
• Once the form is completed, submit it to register the new user. 

3. After successful registration, we can proceed by logging in with the newly created credentials to verify if the XSS vulnerability exists.

4. Now, let’s navigate to the user profile page. 

5. Upon navigating, the user profile page triggers a popup displaying "hello!", which confirms the application is vulnerable to XSS.

Now that, we know Flyspray to be vulnerable, let’s serve the exploit script and feed it to the admin account by changing the Real name into a script code that will allow us to execute scripts to gather the CSRF token and submit a form to create a new admin .

Serve the exploit script and feed it to the admin account

1. First, we have to create a file that containing the exploit code. 

You can find the exploit script in the download text file.  Copy it and paste it into a text editor.  Save the script with the filename, exploit.js .

2. Now, we need to set up a simple HTTP server to host the exploit script. Use Python to serve the script: python3 -m http.server

3. Now, we need to deploy the Exploit.  

• Modify the Real Name field of the logged-in user. Input the following payload in the Real Name field:

• Replace <YOUR_SERVER_IP> with the IP address hosting the HTTP server.

• Navigate to a page where the Real Name field is reflected, such as in bug report comments or the user profile page.

4. Upon clicking the profile icon, the embedded exploit.js script in the field will execute automatically.

5. To verify whether the exploit was successful, check the HTTP server logs on the see lf-hosted Python server.

The logs should confirm that the script was accessed, which indicates it was triggered correctly. 

6. Make sure to work properly,  It is important to add a comment before updating the details to ensure the exploit executes properly. Adding a simple comment like ' Help! ' can help track changes and confirm if the payload triggers successfully.

Re-Login with newly created Credentials

Once confirmed, proceed to logout and re-login using the newly created credentials:

• Username: hacker
• Password: 12345678

With a successful login, we now check if the newly created account has any additional information that will lead us to further exploitation. This can be confirmed by accessing the  dashboard panel .

Within the dashboard panel, there is a  bug report with ID: 2 . Reviewing the task description for this report, reveals a hint, which contains credentials. These credentials might grant access to other systems or services within the network.

Upon reviewing the task description associated with this report, we discovered a hint containing credentials.

With this credential we have we can try to attempt to gain a foothold on the target system.

Foothold

Access Via SSH

To gain Foothold using the provided credentials, we will try to attempt to access the system via SSH. 

However, it was discovered that password logins have been disabled , which is a sensible security measure.

Re-examining the hint reveals a reference to Gitea , indicating that it may be configured internally for Git-related needs.

But, what is Gitea?

Gitea is a lightweight, self-hosted Git service similar to GitHub, offering features such as:

• Repositories for version control
• Issue tracking for task management
• Code review for collaborative development

In this scenario, Gitea might be accessible internally and could contain sensitive information or misconfigurations that can be exploited.

The focus now shifts to Enumerating Gitea for potential vulnerabilities or misconfigurations.

Enumerate Gitea

From the Nmap scan, we previously identified a service running on Port 3000 , running a service resembling Gitea , a self-hosted Git service, which we are looking for enumeration.

Let's access it from the web browser.

Previously, we found a credential that can be used to log in to Gitea . 

• Username: Achilles
• Password: h2sBr9gryBunKdF9.

Click on sign in to navigate to the Sign In page of Gitea and enter the previously foundedcredentials:

Upon trying, we successfully logged in to Achille's dashboard panel . 

Now, let’s inspect Achilles' dashboard panel.

Inspect Gitea Dashboard

Upon logging in as the user Achilles, two repositories are noted:

1. Symfonos-blog
2. Symfonos-API

Inspect the Repo: symfonos-blog. 

Based on the web content and structure, this repository appears to extend the web page's functionality at http://192.168.103.18 .

Inspect the Repo: symfonos-api

The .env file within this repository contains data suggesting it is a custom REST API application running on  Port 5000 .

While the repositories provide insights into the target system, they do not offer a direct path to escalate privileges or gain further access.

Exploiting Gitea service (Manually)

To proceed, we investigate potential exploits targeting the Gitea service. 

We identify a suitable exploit:

Gitea 1.12.5 - Remote Code Execution (Authenticated).

This Python-based exploit allows an authenticated user to execute arbitrary code on the target system. 

By analyzing the exploit script, we can understand how it works and decide to replicate its steps manually to gain a reverse shell.

There are two ways to achieve this —

• Modifying an existing repository or 
• By creating a new one. 

Here, let's modify the  SymfonOS-blog  repository to establish the reverse shell.

But before, we must have to set up a reverse shell listener using Netcat.

First, click on the repository to open it. 

From the SymfonOS-Blog Git Management, locate for Setting.

Then, navigate to Settings , and  under the settings menu, select Git Hooks . 

In the GitHook we can edit hook files to set up custom operation.  Here, we need to edit the  pre-receive  hook by clicking on the edit icon.

Now, let's inject the reverse shell payload script into the hook. 

Once the payload is added, click on Update Hook to save the changes.

However, to trigger the exploit, we need to push a commit to activate the pre-receive hook. 

In the S ymfonos-blog repository, let's modify an existing file to push a commit. I'll choose the index.php file and add a simple comment tag at the end of the PHP code to avoid affecting functionality.

Click on index.php which will redirect us to the page source code, where we have to click on the edit icon to make some changes.
Next, we have to add some PHP code . To not affect the whole PHP code, I use a comment tag to add a comment.

Next, let's add a commit message to reflect the changes we've made. 

Once the message is added, click on Commit Changes.  This action triggers the payload and initiates a connection to our reverse shell listener.

Before committing the changes, ensure that the NetCat listener is running to capture the callback. Once the payload executes successfully, check the listener to confirm an established connection.

Here, we can see in the listener that we have successfully received a connection and gained a foothold on the target system. 

Enumerate the Session

Now, let's enumerate the session to explore possibilities that may help us gain full control over the target system.

First, we need to check for the user context to understand our current privileges. To do this, run the whoami  command in the callback session. This will confirm the active user we are operating as within the compromised system.

Currently, we have initial access as the git user, which provides limited permissions. This means we need to perform privilege escalation or lateral movement to achieve full control over the target system.

Now, let's search for user flags.   Navigate to the git user’s home directory to check for any user flag. 

However, no flag is found for this user, indicating that there might be other users on the system, or we may need to enumerate further to gain higher privileges.

Privilege Escalation

Enumerate System Information

In the privilege escalation phase, our main goal is to conduct deeper enumeration to uncover potential misconfigurations, exploitable vulnerabilities, or overlooked permissions that could allow us to escalate to root or another privileged user. This involves investigating file permissions, SUID files, running services, and scheduled tasks for possible exploitation opportunities.

Since we currently operate with limited user privileges via the reverse shell, we face restrictions in accessing certain files and commands, making a thorough assessment challenging.

To move forward, let's run the sudo -l command to check if the git user has any special sudo privileges.

It appears that the git user does not have permission to run sudo commands. This suggests that other users might have higher privileges. 

Escalate to user, Achilles

Let's change the directory to the /home directory.

Here, we have identified another user directory named Achilles, which means there is a user account with this name.

If we recall from the Flyspray post-exploitation phase, we previously discovered a set of credentials. 

We attempted to use them via the SSH client, but the login failed, possibly due to key-based authentication requirements or SSH configuration restrictions.

Instead of SSH, let's try switching to the  Achilles  user by using the  su  command with the discovered credentials.

Now, we have successfully switched to the  Achilles  user.

However, we notice that the shell is limited or hidden.  To overcome this, let's check if Python is available on the system to help us upgrade the shell. If Python’s presence is there, we can run a command to upgrade our shell for better functionality.

 Now that we have an upgraded shell, let's navigate through the directories to search for a user flag. 

Unfortunately, no flag is found here either.  The final step is to gain superuser privileges, which will allow us to access the root shell. 

To proceed, let's check if the Achilles user has any special sudo privileges by running the sudo -l command.

The output reveals that the Achilles user is allowed to execute the /usr/local/go/bin/go command as root without requiring a password.

The go command, part of the Go programming language environment, can be leveraged to execute arbitrary commands or scripts. 

This provides a direct pathway to escalate privileges and gain root access by crafting and executing a malicious Go script.

Privilege Escalation via Misconfigured Sudo Permissions on Go Binary

First, let's change the directory to the /tmp directory. 

Here, we need to create a Go script that will help us gain a root shell when executed.  Open a text editor and create a new file. Add the following code and save it as root_shell.go .

Now, we need to transfer this script to the target machine. If you recall, we had already started the HTTP server earlier to host the JavaScript file used in exploiting Flyspray .

Switch back to the target machine where we previously navigated to the /tmp directory. Use the wget command to download the script from our attacking machine.

Once the script is downloaded, execute it with elevated privileges using the sudo /usr/local/go/bin/go run <go_script> .

When the script runs successfully, it should spawn a root shell. To verify the access level, run the whoami  command.

Finally, navigate to the /root directory to locate and retrieve the root flag.