Inside this Article:
Hello, everyone! Welcome to a new episode of our VulnHub Walkthrough series. In this video, we’re kicking off a series on the vulnerable machine called " SymfonOS ," which includes six different VMs with varying levels of difficulty. Today, we’ll be exploring the first VM, " SymfonOS 1 ," rated as " Easy ."
To begin, head over to the VulnHub website and download the machine's image file.
.png)
If you're new to VulnHub, make sure to 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 docker environments, designed for learning and practicing security vulnerability assessments and penetration testing. Explore various scenarios and improve your cybersecurity skills.
Now, let’s get started with exploiting this machine!
Settings Up
Previously, we've downloaded the image, the next step is to set up the Virtual image in VirtualBox.
.png)
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.
.png)
Now, our next step involves “ creating a new virtual machine ”. In VirtualBox, click " New " to create a new VM.
.png)
Name it "SymfonOS 1,"
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 and, click on " Finish " to complete the setup.
.png)
Once the setup is finished, you'll see the "SymfonOS 1" vulnerable machine in the VirtualBox manager. For better organization, let me regroup it into
the VulnHub group.
.png)
To ensure that both 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!
.png)
Finally, notice that our vulnerable machine is ready, awaiting a login prompt. Let's dive into the fun!
.png)
Enumeration
Identifying IP address
The initial step in our attack is enumeration, which involves identifying the IP address of our target machine using Net Discover. To execute this, open a terminal and run " netdiscover -i <Specify Network Interface name> ", which in this case is "eth1."
We obtained our target IP address from the scan results: "
192.168.103.13
".
Conduct a Network Scan
Next, we'll conduct a network scan to
identify open ports, a crucial step in the enumeration process. This helps us
understand the attack surface and strategize targeted attacks. For this
purpose, we'll use the popular
Nmap
tool.
On the terminal, Run " nmap -sC –sV <specify the IP address> ”.
In this command,
- " -sC " is used to perform a script scan using the default set of scripts, and
- the "-sV" enables version detection allowing us to identify which versions are running on which port.
After completing the network scan, 5 open
ports with corresponding services were revealed:
- Port 22 TCP: Running an SSH Secure Shell service, which allows remote access to the device if valid credentials are available.
- Port 25 TCP: Running SMTP, a service used for email sending. The scan indicates support for features like STARTTLS (encryption) and large attachments.
- Port 80 TCP: Running an HTTP web server, which serves web content. The scan shows a basic website with no title, hosted on Apache web server software.
- Ports 139 and 445 (tcp): Running NetBIOS services (Samba). These ports are commonly used for file and printer sharing.
We’ll leverage these open ports to gain initial access to the server. Before proceeding, let’s conduct a deeper enumeration of these ports to uncover potential clues or vulnerabilities that might help us gain a foothold or shell access.
Perform Nmap Scripting Engine(NSE)
Now, let’s use the Nmap Scripting Engine to scan for known vulnerabilities on the detected ports and services.
The scan reveals a few notable vulnerabilities:
- Anonymous Diffie-Hellman Key Exchange MitM Vulnerability : This vulnerability affects the SMTP service and weakens encrypted communication, making it susceptible to man-in-the-middle (MitM) attacks.
- Service regsvc in Microsoft Windows systems vulnerable to denial of service : This vulnerability affects the regsvc service, mainly in older Windows systems, and could allow an attacker to crash the service.
Based on our scan results, our next steps involve a closer examination of each service and identified vulnerabilities to assess if they can be exploited to gain shell access. To leverage these findings, we’ll begin with an exploration of each exposed service, starting with the web service.
Web Enumeration and Directory-busting
From the Network mapping, the scan identifies that Port 80 is open, indicating a running web service.
To look at the contents ourselves, open a web browser, and
navigate to the target’s IP address in the URL bar at the top of the window.
.png)
Upon visiting the webpage, we find an image, likely depicting a scene from Greek mythology—possibly the Fall of Phaeton—though it doesn’t provide any useful information for our purposes.
To uncover potential entry points, our next
step is directory busting to search for hidden directories or pages that might
contain valuable information. For this, we’ll use the
gobuster
tool. Run the following command:
where,
- gobuster dir is used to instruct go-buster to perform directory busting.
- -u is used to specify the target URL we want to explore.
- -w is used to provide the path to the wordlist containing common directory names to try.
After running
gobuster
, we didn’t find any valuable information on the website. So, we’ll
shift our focus to other open ports for potential leads.
SMB Share Enumeration
The SMB (Samba) service on Ports 139 and 445 is a good candidate for further investigation, as it might contain accessible or misconfigured shares that can provide useful information.
Sometimes, due to misconfigurations, files
or directories are left exposed and can be accessed without authentication. To
investigate, we’ll use the
smbclient
tool with the
-
N
flag, which allows us to check for available shares without
requiring a username or password.
The command output shows several shared directories:
- print$ : This is typically used for printer drivers and may not contain sensitive data.
- helios : A personal share labeled "Helios," likely belonging to a specific user. This may contain personal files or sensitive data.
- anonymous : An open share, potentially accessible to anyone without authentication. This could be a misconfiguration and may contain useful information.
- IPC$ : An inter-process communication share, generally used for communication between processes and not likely to contain valuable files.
Let’s try to access the shown shared directories.
Because we do not have a valid password we are not able to access it, which results from us access denied error.
But, while I trying to access the "anonymous" share, it was not required, which resulted in us successfully accessing it. For, further exploration, we will list the files and directories in this share.
The file
attention.txt
appears significant, so we’ll download it and inspect its contents
for any helpful information to potentially gain further access to the system.
Upon review, the
attention.txt
file indicates that weak passwords such as "epidioko,"
"qwerty," and "baseball" are in use by some users on this
system. This insight is valuable, as it suggests that users on the target
machine may be using weak or commonly used passwords across various accounts
and services.
Enumerate Helios Share
Initially, when attempting to connect, the system defaults to using the local username, kali , as the target user. As a result, entering the password provided in the hint returns an “Access Denied” error since the username kali does not have permission on this share.
Since we previously discovered a username, helios, we can try specifying this user explicitly by using the ` -U ` flag with helios as the username. With this adjustment, we attempt to log in to the helios share using common passwords. After a few tries, we successfully authenticate with a weak password.
Once logged in, we can list the files and directories within the **helios** share. This allows us to explore its contents, potentially uncovering personal files or sensitive data that could assist in further understanding the system or gaining additional access.
Two files,
research.txt
and
todo.txt
, are present. We’ll retrieve
both files for closer examination.
Once downloaded, we'll examine the contents to determine if they contain critical information, like usernames, passwords, or system-related data that might support our exploitation efforts.
The content of
research.txt
appears to provide background information on Helios, the Greek god
of the Sun, rather than offering technical details, login credentials, or
explicit clues for system access. It describes Helios’s role in mythology,
including his daily journey across the sky on a golden chariot and his
connection to the Colossus of Rhodes, an ancient Wonder of the World.
In summary, while
research.txt
it doesn’t contain actionable information, so, let’s move on to
2nd text file.
The content of
todo.txt
reveals a list of personal tasks but includes a potentially useful directory name.
The line “
Work on /h31105
” suggests that
this directory might exist on the web server (port 80) and could be accessible
via a web browser.
Now, let’s navigate to
the directory
could reveal files, scripts, or pages containing useful information or possibly even vulnerabilities.
.png)
Upon accessing the directory, it looks like
a broken WordPress site. So, let’s access blog content to look at the content.
But it looks like, upon attempting to access the webpage through a browser
window, we are presented with we’re having trouble finding that site.
Here, we can’t connect to the server at “
symfonos.local
”. This type of error
appears due to two underlying reasons.
- The first one is, if we have mistyped the URL address in our URL search bar so that the DNS servers can't find the associated IP address for the mistyped name or
- the second reason is, that we never entered any hostname like “ symfonos.local ” into the search bar, but the website expects us to.
This type of problem can be fixed by
modifying the Local DNS file located in the
/etc/hosts
directory.
Open a terminal and then type nano and then specify the path of the host table, and add the IP address with its associated hostname in the “ /hosts ” table, which would allow your web client to visit the website that was previously reporting an error.
.png)
Now save it using
CTRL + X
and hit
Enter
.
Once this configuration is complete, we can
proceed to reload the target's webpage and verify if it loads successfully or
not. Since the requested hostname now has an association in your “
/hosts
” file,
the website can load without any issue.
After refreshing the browser, we successfully access the blog content.
.png)
Enumerate WordPress Site
Based on prior knowledge, WordPress sites can be vulnerable if not properly maintained, making them a common target for exploitation. To identify potential weaknesses, we’ll use the WPScan tool to analyze the site’s WordPress version, themes, and plugins.
WPScan is a security tool that checks for
vulnerabilities associated with outdated WordPress versions, plugins, and
themes, helping identify if the site is exposed to any known security risks.
If you’re new to using WPScan, I recommend watching this tutorial video and reading my blog post, where I cover WPScan’s functionality and detailed usage.
WPScan: WordPress Security Scanner
Discover WPScan, a powerful security scanner specifically designed for WordPress websites. This guide covers its features, installation process, and how to use WPScan to identify vulnerabilities and enhance the security of your WordPress site.
These resources will help you understand how
to effectively scan WordPress sites for vulnerabilities.
To begin, open your terminal and enter the
command:
wpscan
--url
<URL of the WordPress
site>
.
This command initiates a scan that will analyze the WordPress site for vulnerabilities , misconfigurations , and other security issues.
Now, let’s examine the
Output Highlights
from the
scan, where we can review some significant findings. These findings may reveal
potential vulnerabilities, outdated plugins or themes, weak passwords, and
more, which can help guide further investigation or remediation steps.
- The XML-RPC feature is active on this site. XML-RPC can be vulnerable to certain WordPress attacks, such as brute force or denial of service, making it worth noting for further investigation.
.png)
- The scan identifies the site as running WordPress version 5.2.2 , an older version with known vulnerabilities. This information is valuable, as vulnerabilities in outdated WordPress versions can often be exploited if not patched.
.png)
- The active theme, Twenty Nineteen , is also outdated. Older themes can expose sites to theme-specific vulnerabilities, so this could potentially be an entry point if any unpatched issues exist.
.png)
- WPScan detects the presence of two plugins, with particular attention to the Mail Masta plugin (version 1.0). This plugin has been associated with vulnerabilities in the past, making it especially interesting for our investigation.
.png)
With the Mail Masta plugin identified,
let's search for any documented vulnerabilities specifically affecting version
1.0. If exploitable, these vulnerabilities could provide an initial foothold on
the target system.
Foothold
Search Vulnerability
On the terminal run the following command:
Our search with
Searchsploit
reveals three known vulnerabilities for the Mail Masta 1.0 plugin, including Local File Inclusion (LFI) and SQL
Injection. The LFI vulnerability stands out, as it could allow us to read files
on the server by manipulating the file path in the URL. This access might reveal
sensitive information, such as configuration files or credentials, helping us
further compromise the target system.
Let's save and examine the exploit file 40290.txt to gain further insight into leveraging the LFI vulnerability.
Once downloaded, we’ll thoroughly review the steps provided in the exploit.
The 40290.txt file documents a Local File
Inclusion (LFI) vulnerability in the Mail Masta WordPress plugin.
This vulnerability allows attackers to include files from the server by passing
a specifically crafted parameter to a vulnerable file inclusion function.
Here’s how the exploit works:
Now, let’s Understand the Vulnerability. The plugin
files
count_of_send.php
and
csvexport.php
use
include($_GET['pl']);
without proper input validation, meaning they can accept user-supplied paths
and include files directly from the server. This enables an attacker to read
sensitive files on the system if they know the file paths.
A common way to verify this type of vulnerability is
by attempting to load sensitive files like
/etc/passwd
on
Linux systems, which contain a list of user accounts.
Using the provided example URL, we can test for this vulnerability.
For this purpose, first, we have to replace
target-server
with
the actual target IP or domain. If successful, the server will display the
contents of
/etc/passwd
,
confirming that LFI is possible.
.png)
As a result, The LFI exploit
successfully displayed the contents of
/etc/passwd
.
After confirming the LFI vulnerability, we can attempt to access other critical
files on the server that may contain sensitive information, such as
wp-config.php
. This file
typically holds database credentials and other application secrets, which could
facilitate further exploitation.
However, the exact location of wp-config.php is still being determined. To move forward, we might aim to establish a reverse shell for deeper access.
Exploiting SMTP service with Log Poisoning
Upon examining open ports, we observe that the SMTP service is active, indicating a potential mail server connection.
Based on the /etc/passwd output, it appears the default mail directory is /var/mail , though it is currently inaccessible. Mail logs or stored data may sometimes be separated by user ID.
Since we have identified the user ID as helios , this might provide a way to monitor or interact with incoming mail activity.
.png)
In a previous Nmap scan, we identified a vulnerability within the SMTP service, specifically an Anonymous Diffie-Hellman Key Exchange MitM (Man-in-the-Middle) vulnerability.
This vulnerability allows potential exploitation for Remote Code Execution (RCE), enabling us to inject commands that could lead to compromising the mail server.
By exploiting this vulnerability, we aim to establish a reverse shell and potentially escalate privileges, gaining full control over the target system.
To exploit this vulnerability, we need to
send an anonymous email via SMTP using specific commands. Telnet or Netcat can
facilitate this process, allowing us to directly interact with the SMTP server.
To initiate the session, on the terminal connect to the SMTP server on port 25.
At this stage, we see the server’s
greeting, indicating the SMTP session is established.
Next, use the
HELO
a command followed by a domain name (either our domain or a random
one) to introduce ourselves to the server.
The server responds with
250
, confirming that it acknowledges our introduction.
Now, we need to specify the Sender. Use the MAIL FROM command to define the sender's email address.
The server’s
250 2.1.0 Ok
response confirms the sender’s address.
Now, we need to specify the Recipient.
Use
the
RCPT
TO
command to set the recipient's email address.
In this case, we’ve determined that the target’s mail username is
helios
.
Now, we need to compose the Message. To
initiate message composition, use the
DATA
command.
This command indicates the start of the email content.
Now, let’s write the Message. Now, instead of a standard email message, we’ll insert our RCE code.
This code snippet will allow us to execute system commands on the target server if successfully triggered.
Ending the message with a
single period (
.
)
on a line by itself signals to the SMTP server that the message is complete.
After injecting the PHP payload via email,
we can refresh our browser or monitor server logs to check if the payload executed
successfully. This approach confirms if our log poisoning attempt has allowed
for command injection on the target system.
To start, we’ll send basic commands through
the
cmd
parameter to test for
Remote Code Execution (RCE)
.
.png)
Once we verify
that commands can be executed, we’ll proceed with a reverse shell for a more
interactive connection.
Gain ReverseShell
To establish a reverse shell, we’ll craft a payload for the target’s RCE URL that will connect back to our Kali Linux machine.
.png)
For this payload, include the Kali Linux IP address and specify the listening port. On the Kali machine, set up a Netcat listener to receive the connection from the target.
Once the reverse shell payload is executed on the target, a successful connection will grant us shell access to the system.
After initiating the listener, a connection is established from the target IP address, confirming that the payload has successfully triggered a callback to the listener.
Upon initiating the listener, the target system connects back to our Kali machine, and we confirm the callback by checking the connection. The target's IP address in the listener logs indicates that the payload has successfully triggered the reverse connection.
Now, let's confirm the shell is working by running a simple command, such as `id`.
This reveals the current user and group information, showing that the user is " helios ." However, while the shell is functional, it lacks interactivity. To make the shell more usable, we check for Python by running ` which python `, which returns its location at ` /usr/bin/python `. We then run ` python -c "import pty; pty.spawn('/bin/bash')" ` to spawn a pseudo-terminal, improving shell interactivity.
After enabling the interactive shell, we
navigate to the
/home
directory to look for a
user flag. Inside, we locate a directory belonging to the user
"
helios
."
We list its contents using
ls -al
, but find no user flag present.
To proceed, we need to escalate privileges to
gain root access, as standard user privileges limit our ability to fully
investigate the system.
Privilege Escalation
In privilege escalation, our main objective
is to gather system information and identify any potential vulnerabilities or
misconfigurations that could allow us to gain elevated privileges, ideally
achieving root access. However, because we are connected through a reverse
shell, we only have limited user privileges, which restricts our ability to
access certain files and commands needed for a full assessment.
SUID Enumeration
To identify privilege escalation
opportunities, we search for files with the
SUID (Set User ID)
bit set, which
allows a user to execute these files with the permissions of the file
owner—usually root. We use the command
find / -perm -4000 2>/dev/null
to locate files with SUID permissions.
This search reveals several
binaries, including
/opt/statuscheck
, those that appear
unusual and warrant further investigation.
Upon running /opt/statuscheck , we discover that it outputs HTTP header data, indicating it interacts with a web server, possibly with elevated privileges. This suggests we might exploit it to gain root access.
Exploiting SUID Binary with Path Injection
We proceed by checking the file type of /opt/statuscheck with the ` file ` command, which identifies it as a 64-bit ELF executable with SUID permissions.
To explore further, we run the ` strings ` command on it, which extracts embedded strings.
Among them, we find
curl -I
and
http://localhost
, suggesting that the binary uses
curl
to make HTTP
requests.
To exploit this, we create a malicious ` curl ` file in the ` /tmp ` directory. We first navigate to ` /tmp ` with ` cd /tmp `, then use ` echo "/bin/sh" ` to create a file that will launch a shell when executed. We change its permissions to ` chmod 777 curl ` to make it executable. Next, we need to ensure the ` /tmp ` directory is prioritized in the `PATH` environment variable, so our fake ` curl ` is used when ` /opt/statuscheck ` is executed.
We prepend ` /tmp ` to the `PATH` with ` export PATH=/tmp:$PATH `. Afterward, we run ` /opt/statuscheck ` again, which now executes our malicious ` curl ` and spawns a root shell.
To confirm root access, we run ` whoami `, which should return "root."
We then navigate to the ` /root ` directory and list its contents with ` ls -al `, where we find a file named ` proof.txt `.
Finally, we view the contents of `proof.txt` using the ` cat ` command.
The file confirms successful root access
and includes a congratulatory message, marking the completion of the task.
If you have any doubts or questions, feel free to leave them in the comment section.
