Inside this Article:
- Setting Up
- Enumeration
- Identify the IP address
- Conduct Network Scan
- Web Enumeration and Directory Busting
- Analyze Potential Risks
- Foothold
- Exploiting Shellshock vulnerability
- Gain Reverse Shell
- Upgrade the Reverse Shell
- Access the user flag
- Privilege Escalation
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.
Vulhub: Vulnerable By Design
Vulhub provides a collection of pre-built vulnerable environments. This resource is designed to help you practice penetration testing and vulnerability assessment skills on a variety of systems.
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.
.png)
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.
.png)
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.
.png)
Now, allocate the desired amount of RAM.
.png)
Next, select " Use an existing virtual hard disk file " and locate the VMDK file.
.png)
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.
.png)
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 ."
.png)
Since everything is ready, let’s attempt to start the VM to check if it works.
.png)
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:
- Port 21 (TCP): Running FTP (File Transfer Protocol), with the server identified as ProFTPD 1.3.5b.
- 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.
- 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.
.png)
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.
.png)
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
.png)
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.
.png)
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.
.png)
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.
.png)
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.
.png)
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/
.
.png)
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.
.png)
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
.png)
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.
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 -i option specifies the interface name, and
- the -w option 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.
.png)
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.
.png)
Upon upload, we need to accept the terms of service to continue. After a successful upload, the tool will generate a detailed report.
.png)
Click on "
View Report
."
.png)
In the found credentials section, it shows 1 in red, which indicates that a credential is present.
.png)
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.
.png)
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:
- Access to files or processes owned by the gods group.
- Potential influence 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.
pspy64 - Process Monitoring Tool
Download pspy64, a tool for monitoring processes without root permissions. This utility is essential for analyzing and understanding process behaviors on Linux systems.
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) .
.png)
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:
- The ftpclient.py program automates the upload of a file to an FTP server running on 127.0.0.1 (localhost).
- It establishes
an FTP connection using the credentials and the script
navigates to the
/srv/ftp/
directory on the FTP server.
- 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.
- 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.
.png)
This
setup provides two potential avenues for exploitation:
- 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.
- 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.
.png)
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.
