Symfonos 3 || 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 3rd virtual machine in the series, " SymfonOS 3 ." 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!

Setting Up

After downloading the image, extract the 7Z archive to access the virtual machine files. 

Inside, you’ll find several essential files, including the VMDK file. Now, we are creating a new virtual machine. 

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

Specify the Name and Operating System

• Name it " SymfonOS 3 ," 
• 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 " and locate the VMDK file.

Now, click on "Finish" to complete the setup. Once it's finished, you'll see the " SymfonOS 3 " vulnerable machine in the VirtualBox manager. Let me regroup it into the VulnHub group for better organization.

To ensure that your  Kali Linux machine (used for attacks) and the vulnerable machine are connected to the same network, 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.

Once it's ready, you should see a login prompt, indicating that everything is set up and we can begin our exploration! 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 the network interface name>

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.15” .

Conduct Network Scan

Next, we'll conduct a network scan to identify open ports on the target, which is an essential step in the enumeration process. Identifying open ports gives us insight into the network’s attack surface, allowing us to pinpoint specific services that might be vulnerable to exploitation. To perform this scan, we’ll use the widely used network scanning tool, Nmap.

In the terminal, run:  nmap -sC –sV <specify the target IP address>

In this command:

• -sC initiates a script scan using Nmap's default scripts, which probe for additional details about each service and identify possible vulnerabilities.
• -sV enables version detection, allowing Nmap to determine the version of services running on open ports.

Once the scan is completed, the results reveal three open ports with their respective services:

1. Port 21 (TCP):  Running FTP (File Transfer Protocol), with the server identified as ProFTPD 1.3.5b.
2. Port 22 (TCP): Running SSH (Secure Shell), which provides remote access if valid credentials are available. Although SSH is generally secure, weak or default passwords could make it exploitable.
3. Port 80 (TCP): Running HTTP on a web server. The scan shows a basic website with no title, hosted on Apache HTTPD. This service is a common entry point for attacks and may contain web-based vulnerabilities.

These open ports 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 or shell access. This focused analysis will guide us in developing a strategic approach to compromise the target.

Web Enumeration and Directory Busting

Our next steps involve investigating potential vulnerabilities to identify opportunities for shell access or other footholds on the target system. 

Since the  HTTP web server  is running on Port 80, we’ll begin by examining it, as web services often serve as primary access points and may reveal additional attack vectors.

To start, access the web service by entering the target’s IP address directly into a web browser. 

The page loads with visual content depicting a scene from Greek mythology, likely centered around the figure of Cerberus . The central figure is a monstrous three-headed dog, commonly associated with guarding the underworld. Its three heads have menacing expressions and fiery eyes. 

A shadowy figure, likely Hades , the god of the underworld, stands beside Cerberus, holding what appears to be a spear or staff.

To uncover hidden clues, inspect the page source. 

Within the source code, we discover a hint:

“Can you bust the underworld?”

This clue suggests the potential presence of a hidden file or directory, prompting further exploration.

Directory Enumeration of the Base URL

Let now Perform Directory Enumeration. To locate hidden resources, we’ll use directory enumeration tools such as dirb or Gobuster . 

These tools will systematically probe for common directories and file names, which could uncover additional files or directories that are not directly visible from the website. This process will help us identify possible attack vectors or sensitive information that can aid in further exploitation.

Using dirb, we will start scanning the base URL. 

The results reveal:

• /cgi-bin/ (403 Forbidden ): Suggests a directory exists but requires further probing.
• /gate/  (Accessible): Indicates a subdirectory worth investigating.
• /index.html (200 OK): The main page.
• /server-status (403 Forbidden): Suggests server monitoring data is restricted.

The accessible /gate/ directory stands out as a point of interest. 

/gate/  Directory Enumeration

Navigating /gate/ directory in the browser reveals content that closely resembles the main page.

The imagery evokes a sense of an underworld setting, characterized by a dark and ominous atmosphere. A fiery glow illuminates the scene, enhancing the eerie vibe, while ruined structures in the background contribute to the impression of desolation and mystery. 

This thematic presentation aligns with the mythology-inspired elements seen on the main page, suggesting that this directory may contain additional clues or serve a specific purpose in the context of the target system.

We will Perform another directory-busting scan, this time targeting the /gate/ directory and also we switch to a more comprehensive wordlist to expand the search.

But it looks like, dirb is not able to enumerate directories, so we will use gobuster for this purpose.

This extended scan uncovers:

• /cerberus/ (Status: 301): A directory that redirects to http://192.168.103.15/gate/cerberus/

The discovery of the /cerberus/ directory is significant. It suggests another layer of content or functionality, potentially exposing vulnerabilities or providing further clues for exploitation.

/cerberus/  Directory Enumeration

Next, we’ll explore the /cerberus/ directory to analyze its contents and continue our enumeration process.

Upon loading the page, we see an image depicted on the webpage:

The image looks like a three-headed dog, likely Cerberus from Greek mythology, depicted in a fiery and menacing setting. 

This visual, however, does not provide any immediate hints. 

Reviewing the page source also reveals no additional clues, prompting us to extend our search.

Using dirb to enumerate the  /gate/cerberus/  directory yields:

• index.html : This file loads successfully but does not appear to hold significant information.
• tartarus/ : A new directory  was discovered, indicating deeper directory nesting.

Also dirb automatically successfully enumerates the directory of tartarus which reveals:

• index.html: which indicates the home page of tartarus. 
• research: which looks like a large file of size 6,825 bytes which may potentially contain sensitive information or clues.

This structure indicates an organized directory system designed to conceal information. The research file is particularly noteworthy and warrants closer examination for actionable insights.

Enumerate /research directory

It’s time to retrieve and analyze the research file. Use tools like curl , wget , or direct browser access to download the file. 

Upon inspecting its content, we find extensive information about research on gods and demons . 

While this content may hold potential clues or sensitive data, its sheer volume makes manual analysis impractical. It might be useful for generating a custom wordlist for further enumeration, but we cannot proceed directly with it for now.

Instead, the discovery of the /tartarus/ directory is a significant breakthrough. 

This new directory suggests an additional layer of content or functionality that could provide actionable insights or lead to further vulnerabilities. 

Enumerate /gate/tartarus directory

Let’s focus our attention on exploring /tartarus/ to determine its potential.

Navigating this directory presents a dramatic and chaotic visual scene set in a dark, cavernous underworld. 

This imagery aligns with Tartarus from Greek mythology—an abyss used as a prison for the wicked and the Titans, symbolizing torment and eternal darkness.It's a place of eternal darkness and punishment, located far below Hades. 

Let now inspect the page source for /tartarus/ .

Inspecting the page source for /tartarus/ reveals a new hint:

“The underworld can be cruel… but it can also be misleading.”

This suggests that our approach to the enumeration process might be flawed, or we may be overlooking something critical. It indicates that we may have been enumerating directories incorrectly and need to adjust our strategy.

Previously, we discovered a /cgi-bin/ directory, which could potentially reveal exploitable configurations. 

 

Enumerate /cgi-bin directory

The /cgi-bin/ directory is a standard location for Common Gateway Interface (CGI) scripts, commonly used to execute server-side code.

Upon visiting it, we encountered a " permission denied " message. 

However, directories like /cgi-bin/ or /server-status often contain valuable information such as server configurations, running processes, or debugging data. These can be leveraged by attackers to exploit vulnerabilities.

To further investigate, we’ll perform directory busting again to locate any accessible resources. 

This time, the search reveals a new directory: /underworld , which returns a 200 OK response, indicating it is accessible.

Enumerate /cgi-bin/underworld directory

Upon accessing underworld , we’re presented with information about the system’s uptime and load averages. 

This indicates that the script in this directory outputs server status, which could provide useful details for further reconnaissance. 

Given this, we need to analyze the potential risks.

Analyze Potential Risks

The underworld directory is highly suspicious and warrants a closer inspection. CGI scripts in directories like these are often vulnerable to various exploits, including:

• Arbitrary code execution
• Path traversal attacks
• Shellshock vulnerability

Based on the information gathered, the Shellshock vulnerability is likely a potential risk. This vulnerability allows attackers to execute arbitrary code on the server, making it a critical point for further exploitation.

To investigate further, we'll proceed by testing the target for vulnerabilities, specifically related to OS command injection. This may include testing for Shellshock , which could potentially provide a foothold on the target system.

Foothold

Exploiting Shellshock vulnerability

We'll use the Commix (short for COMMand Injection eXploitation) tool to test the target for  Shellshock  and command injection vulnerabilities. 

This tool automates the detection and exploitation of command injection flaws, making it a valuable resource for identifying potential vulnerabilities that could grant initial access to the system.

We run Commix with the target URL using commix -u <specify the target>

The Commix will analyze the target and determine whether the script is potentially vulnerable. During the scan, Commix will prompt us to enable the Shellshock module . When asked, type  y  to enable it and initiate heuristic tests for the Shellshock vulnerability.

The Commix tests for command injection through the User-Agent HTTP header . In this case, we discover that the User-Agent header is injectable, confirming that the Shellshock vulnerability can be exploited using this header.

Once the Shellshock vulnerability is successfully exploited, the tool will confirm the script’s susceptibility. It will then prompt for a pseudo-terminal shell. Type  Y  to continue, which will allow Commix to initiate an  OS shell  on the target system.

At this point, a pseudo-terminal shell is opened, granting us direct interaction with the target system. We now have a command shell through which we can execute additional commands and explore the system for vulnerabilities or sensitive information.

To check the available commands in the shell, use the ? command, which will list the options available. 

With this pseudo-terminal , we will now establish a reverse shell to connect from the target system back to the attacker's machine using Netcat .

Gain Reverse Shell

Before we execute the reverse shell, we need to set up a listener on our attacking machine. This can done using Netcat , which will listen for the incoming connection from the target system. 

Once the listener is ready, we can execute the crafted reverse shell command.

Here, 

• <Listening IP address>: Specify the listening host IP address, which is our Attacking machine IP address. If you do not know, then use the  ifconfig command.
• <Listening Port>: Specify the Port where it listening to after execution.

Now, execute the crafted command in pseudo-terminal .

Upon successful execution, a reverse shell will be established, connecting the target system to our attacking machine and providing us with interactive access.

For better usability and control over the shell, we need to upgrade it. 

Upgrade the Reverse Shell

First, we will check if Python is available by running the command: which python

Since Python is present, we will use it to spawn a more stable shell by running the command: 

python -c "import pty; pty.spawn('/bin/bash')"

This command will give us a fully interactive shell. Additionally, we set the terminal type with:

export TERM=xterm

This helps ensure smoother interaction with the remote shell, improving the post-exploitation workflow and allowing us to interact with the target system more effectively.

Since we now have user access, let's check if there are any flags present. 

Access the user flag

We start by using the cd command to navigate to the Cerberus home directory . 

However, it appears that the default directory is not set, so we will change the directory manually.

First, we navigate to the /home directory and list the files and directories. 

Here, we find two directories: Cerberus and hades . These appear to be the home directories of the users on the system.

Next, we change the directory to Cerberus and inspect the files and directories. 

Inside, we find the usual default user configuration files, such as .bashrc and .profile , as well as a .bash_history file, which is linked to /dev/null (indicating that history logging is disabled). However, we do not find any flags here.

This suggests that there may be a flag in the Hades user's home directory. To access this, we need to escalate privileges to the Hades user. We will need to enumerate the system further to find a way to escalate our privileges and gain access to the Hades user account.

Privilege Escalation

Escalate the user to Hades 

In the privilege escalation process, the primary objective is to gather system information and identify any vulnerabilities or misconfigurations that could grant elevated privileges, potentially leading to root access. However, since we currently have limited user access through the reverse shell, we cannot access certain files or commands necessary for a comprehensive assessment.

Earlier, we noticed that we don’t have the necessary permissions to perform a full user privilege enumeration.

To move forward, we run the sudo -l command to check if the cerberus user has any sudo privileges. 

The command returns a " sudo: command not found " error, indicating that the cerberus user does not have sudo access. 

To gather more details, we run the id command, which provides the user's UID, GID, and group memberships.

The id command reveals the user's UID, GID, and group memberships.

In this case, the cerberus user is a member of the www-data and pcap groups. 

• The www-data group is commonly used by web services, 
• while  pcap indicates permission to access packet capture.

 Tools like tcpdump could be useful for further privilege escalation.

Investigating the pcap Group for Network Capture Opportunities

To verify if tcpdump is available, we use the command:  which tcpdump

Upon execution, it confirms that the tcpdump binary is located in /usr/local/bin/. This means we can use tcpdump to capture network traffic on available interfaces.

Next, we check the available network interfaces by running tcpdump -D

The available interfaces are:

• enp0s3 (primary network interface) ,
• any ( captures traffic from all interfaces) ,
• lo ( loopback interface) .

We proceed by using tcpdump to capture network traffic from all interfaces. 

Where,

• The -ioption specifies the interface name, and 
• the -woption is used to specify the file where the captured data will be stored.
• We append the &symbol to run the command in the background.

The command starts capturing traffic and writing it to the capture.pcap file.

Once the traffic is captured in capture.pcap, we need to transfer the file to our machine for analysis. 

Analyzing the Captured PCAP File

This can be done using tools like Wireshark for detailed graphical traffic analysis or tshark , a command-line tool for quicker queries.

Serve capture.pcap

To serve the capture.pcap file, we use Python’s built-in HTTP server . 

1. First, we have to check the Python version on the target machine. 

2. Since the target is running Python 2, we use the command: python -m SimpleHTTPServer

The Python HTTP server is now running on the target machine, serving the  capture.pcap  file 

3. Now, we can use wget to download the file to our local machine.

The file is now successfully transferred using wget on the attacker's machine.

Next, we analyze the PCAP file for Credentials in plaintext (e.g., HTTP, FTP, etc.), Connections to unusual hosts , and  Traffic anomalies (such as suspicious protocols or high-volume transfers).

Analyze the PCAP file using A-Packets

For this analysis, we won’t use Wireshark or tshark. Instead, we’ll upload the file to A-Packets, an online tool, which will automatically filter and highlight key findings.

To upload the captured PCAP file, click on "Upload PCAP file," which will redirect to an area where you can either drag and drop the PCAP file or upload it from your local device.

Upon upload, we need to accept the terms of service to continue. After a successful upload, the tool will generate a detailed report. 

Click on " View Report ."

In the found credentials section, it shows 1 in red, which indicates that a credential is present. 

Yes, this appears to be a credential used to connect back to the FTP server.

Now that we have a credential, it will help us access the user hades and escalate further. We can initiate the su command to switch to the substitute user. 

However, when I stopped the previously used Python HTTP server, it disconnected the connection.

This username works for FTP, as found from analysis, but if we try it on SSH to establish a connection, as,  SSH proves to be more stable.

Establish a connection using SSH

Upon trying with the credential, I successfully connect via SSH. 

Access the user flag

Now that we are logged in as hades, we check for any flags in this user's directory. 

However, there is no flag in this directory. It seems the flag is only accessible at the root level, but we currently lack the necessary permissions to access the root directory.

Escalate to Root

Our objective is to escalate privileges to root by identifying system vulnerabilities or misconfigurations that may allow us to gain root shell access. However, I believe we still do not have sufficient user privileges, which restricts our ability to access certain files and commands for a full assessment.

To explore potential avenues for escalating to root, we first check for sudo privileges. 

Running the sudo -l  command fails because sudo is not available on the system, indicating that we cannot escalate via sudo.

Enumerate System information

Next, we need to enumerate the user’s access. We use the id command to display the user and group identity of the Hades user. This command will reveal useful information about the user’s UID, GID, and the secondary groups they belong to.

From the output of the id command, we gather the following information:

• uid=1000(hades) : The primary user ID for the hades user is 1000. This UID determines the user’s identity when executing processes or accessing resources.
• gid=1000(hades) : The primary group ID for the hades user is also 1000, indicating ownership of resources tied to the hades group.
• groups=1000(hades),1002(gods) : The hades user is a member of the gods group (ID 1002). This provides additional permissions:
• Accessto files or processes owned by the gods group.
• Potentialinfluence from cron jobs or processes initiated by members of the gods group.

This confirms the user's primary and supplementary group memberships. 

Examining CRON Jobs and Process Monitoring

To investigate the gods group’s influence on running processes, particularly cron jobs, we use the pspy64 tool.

pspy64 is a lightweight tool designed to monitor processes executed on a system without requiring root permissions. It helps identify scheduled tasks, group-level activities, and commands executed by various users or groups.

Steps to Deploy and Run pspy64

1. First, Download pspy64 from GitHub onto the attacker’s machine.

2. Once downloaded, we need to transfer the Tool to the Target system. So, we have to set up an HTTP server using Python.

3. On the target machine, use wget to download the tool. 

4. Ensure the pspy64 binary has executable permissions by listing files and directories. If not, modify them using: chmod +x pspy64

5. Execute the tool on the target to monitor system processes in real time.

• The output reveals critical details about processes running under UID 1001 , associated with the gods group. 
• These processes inherit the permissions granted to the gods group, allowing specific actions or access.

Upon further analysis of the logs, a key finding stands out— an interesting factor that may allow escalation to a root shell .

Identifying and Analyse Root-Level Processes

The logs highlight a process running with root privileges (UID=0) . 

This includes CRON jobs and other root-level activities that present potential privilege escalation opportunities. 

Let’s examine these findings:

• The log shows, a series of processes running with root privileges (UID=0), including CRON jobs, which execute commands on a schedule. 
• Among these, a CRON job runs  /usr/bin/curl --silent -I 127.0.0.1 > /opt/ftpclient/statuscheck.txt , indicating it writes to a specific file. 
• If this file or its parent directory is writable by a non-root user , it becomes a potential target for tampering, such as replacing the file with a symlink to a critical system file like,  /etc/crontab , enabling the insertion of malicious commands. 
• Another key process is the execution of /opt/ftpclient/ftpclient.py , a Python script that runs as root. 
• If this script is writable, an attacker can modify it to include arbitrary code or commands, like spawning a reverse shell or executing /bin/bash .
• The ProFTPD service is also running and may present vulnerabilities. 
• If it is misconfigured or outdated, allowing attackers to exploit it for privilege escalation.

These factors, including the root-level CRON jobs, writable resources, and potentially vulnerable services, create an opportunity for privilege escalation and unauthorized access to the root.

Gain Root Shell via Writable System Library and CRON Job Exploitation

Next, we should review the /opt/ftpclient/ftpclient.py script to understand its functionality and evaluate how it might be exploited. 

Upon analysis, the script reveals:

1. The ftpclient.py program automates the upload of a file to an FTP server running on 127.0.0.1 (localhost). 
2. It establishes an FTP connection using the credentials and the script navigates to the /srv/ftp/ directory on the FTP server.
3. The upload() function handles the upload of the /opt/client/statuscheck.txt file to the server's current working directory using the ftp.storbinary() method.
4. After successfully uploading the file, the connection is terminated with ftp.quit() .

Upon correlating this script with the CRON job, we observe that the CRON job periodically executes ftpclient.py with root privileges to upload the statuscheck.txt file. 

This setup provides two potential avenues for exploitation:

1. The first method is by manipulating the Input File. Here, the statuscheck.txt file, used as input, might be writable by non-root users. If this is the case, injecting malicious content or commands into this file could result in those commands being executed with root privileges during the upload process.
2. The other one is by tampering with the Script. If the ftpclient.py script itself is writable, it could be modified to include malicious commands or create a reverse shell, which would also execute with root privileges during the scheduled CRON job.

To proceed, the next logical step is to thoroughly investigate the file and directory permissions for /opt/ftpclient/ftpclient.py, /opt/client/statuscheck.txt , and their parent directories. This investigation will help determine potential points of tampering that could be exploited to gain root access.

Tampering with the Script

Rather than modifying the current Python program directly, which might cause issues, we will use a different approach. The script relies on Python's ftplib library. If we can modify this library with injected malicious code, it will execute the next time the CRON job triggers the script.

Let's start by locating the ftplib library. 

Using the command, we identify the locations of the ftplib.py library files for Python 2.7 and Python 3.5.

Next, we check the permissions on /usr/lib/python2.7/ftplib.py

The output reveals that the file is writable by the current user ( -rwxrw-r-- ), which indicates an improper configuration, as critical system libraries should not be user-writable.

Since the library is writable, we can append malicious code to it. 

We choose to append a reverse shell command to the library. But before doing that, we need to set up a Netcat listener on the attacker's machine to receive the reverse shell connection.

Once the listener is set up, we execute the following command to append the reverse shell to ftplib.py. 

This command uses the os module to execute a reverse shell, connecting back to the attacker's machine on the IP address and port 1234.

Next, when the CRON job runs and executes the ftpclient.py script, it imports ftplib, which now contains the malicious code. This causes the reverse shell to execute with root privileges, establishing a connection back to the attacker.

Finally, we now have a root shell. 

Running the whoami command confirms our assumption. 

Upgrade Shell and access root flag

The shell does not look like interactive.  To spawn a fully interactive shell, we run the command: 

python -c "import pty;pty.spawn('/bin/bash')"

This provides us with a fully interactive root shell, giving us full control of the system. We can now change the directory to /root and check for the root flag. 

Using the cat command, we reveal the root flag.

Finally! we now have the root flag.