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 6th and our last virtual machine
in the series, "SymfonOS 6." This intermediate, OSCP-like, real-world scenario machine is designed to highlight the
importance of understanding vulnerabilities and how to exploit them
effectively.
Let’s get started!
To begin, head over to the VulnHub website and download the machine's image file. If you're new to VulnHub, check out our playlist for helpful guides on how to use the platform.
Discover Vulhub, a collection of pre-built Docker environments for security testing. This platform offers a wide range of vulnerable systems to help enhance penetration testing and security assessment skills.
Now, let’s get started with exploiting this machine!
Settings Up
Previously, we downloaded all the 6 image files.
So, our next step is, to set up the Virtual image in VirtualBox. The downloaded image file is in the form of 7Z format, so start by extracting the archive to access the files within. You’ll find several files, including the essential VMDK files, in the extracted folder.
Now, our next step involves “creating a new virtual machine”.
Creating a New VM
In VirtualBox, click "New" to create a new VM.
Name it "SymfonOS 6," set the OS type to Linux, and choose "Other Linux 64-bit" for the version since the specific distribution is unknown.
Now, allocate the desired amount of RAM.
Next, select "Use an existing virtual hard disk file" locate the VMDK file, and click on "Finish" to complete the setup.
Once the setup is finished, you'll see the "SymfonOS 6" vulnerable machine in the VirtualBox manager. For better organization, let me regroup it into the VulnHub group.
Network Configuration
To ensure that both your Kali Linux machine (used for attacks)and the vulnerable machineare connected to the same network, do we have to make sure they're both connected via a host-only Adapter?
So, go to “settings” and change the Network adapter to "Host-Only."
Since everything is ready, let’s attempt to start the VM to check if it works.
Start the VMs
Once it's ready, you should see a login prompt, indicating that everything is set up and we can begin our exploration!
Finally,
notice that our vulnerable machine is ready, with a login prompt awaiting.
Let's dive into the fun!
Enumeration
Identify the IP address
The first step in our attack is
enumeration, where we identify the IP address of our target machine using the netdiscover tool. This step helps map the network and locate devices that are
up and accessible.
To execute this, open a terminal and enter: netdiscover –i <specify Network Interface name>, which in this case is eth1.
┌──(kali㉿kali)-[~]
└─$ sudo netdiscover -i eth1
The
command output displays a list of devices detected on the network, showing
their IP and MAC addresses, as well as the associated vendor.
Currently scanning: 192.168.108.0/16 | Screen View: Unique Hosts
3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180
From these results, we can see several IP
addresses along with their corresponding MAC addresses. Our target machine’s IP
address is identified as “192.168.103.18”.
Mapping the Network
Next, we'll perform a network scan to
identify open ports on the target, which is a critical part of the enumeration
process. Identifying open ports provides insights into the network’s attack
surface, helping us pinpoint services that may be vulnerable to exploitation.
For this task, we’ll use the popular network scanning tool, Nmap.
To execute the scan, open a terminal and
run the command:
┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV 192.168.103.18
In this command:
-sC: Performs a script scan using
Nmap's default scripts to gather additional information about services and
identify potential vulnerabilities.
-sV: Enables version detection to
determine the versions of services running on open ports.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-12-01 13:17 EST
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at https://nmap.org/cgi-bin/submit.cgi?new-service :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 95.14 seconds
┌──(kali㉿kali)-[~]
└─$
After the scan is completed, the results
reveal four open ports with their respective services:
Port 22 (TCP): Running SSH (Secure Shell), which
allows remote access with valid credentials. Although generally
secure, weak or default passwords could make it vulnerable.
Port 80 (TCP): Running HTTP on a web server. The
scan shows a basic website with no title hosted on Apache
HTTPD, which may contain web-based vulnerabilities.
Port 3000 (TCP): Running a service resembling
Gitea, a self-hosted Git service. Potential vulnerabilities include weak or
default credentials, unpatched security flaws in outdated versions, or exposed sensitive APIs.
Port 3306 (TCP): RunningMariaDB, a database service. Unauthorized access is disabled, but
vulnerabilities may include brute-force attacks on credentials, outdated
software versions, or misconfigured permissions.
Port 5000 (TCP): Hosting a minimal web service that
returns HTTP errors such as "404 Not Found." Potential risks include exposed endpoints, misconfigurations, or exploitable
vulnerabilities in
web service logic.
These open ports may present potential
entry points into the target system. The next step is to conduct a deeper
enumeration of each service to uncover vulnerabilities or clues that could
facilitate initial access or shell exploitation. This analysis will guide the
development of a strategic approach to compromise the target.
Web Enumeration
Our next steps focus on identifying
vulnerabilities to gain shell access or another foothold on the target system.
The HTTP web server, running on Port 80, will be our starting point, as web
services are often key entry points and can uncover additional attack vectors.
Begin by accessing the web service by
entering the target's IP address into a web browser.
The displayed webpage
features an image depicting a Greek mythology scene, likely referencing the
Trojan War or a similar legendary battle.
Inspecting the page source using CTRL + U does not reveal any
hidden information.
Web Directory Enumeration
To discover hidden resources, we will perform directory enumeration using
tools like dirb or Gobuster, which scan for
accessible directories or files not immediately visible in the web interface.
These tools systematically scan for common
directories and file names that may not be directly visible on the website,
potentially revealing sensitive files or directories that could aid in further
exploitation.
Execute the appropriate commands in the terminal to initiate the
enumeration process.
The results of directory enumeration
typically highlight potentially sensitive or hidden files and directories on
the web server. Each file or directory's HTTP response code and status provide
critical insights into access restrictions and potential security risks.
Theindex.html file, with a 200 OK status, confirms it is
accessible and serves as the homepage—already viewed in our initial browser
access.
Directories likeflyspray/ and posts/,
returning 301 Moved Permanently, suggest
redirections to other locations. These might lead to hidden web applications,
management interfaces, or repositories, warranting further exploration.
To gather more information, let’s explore
these paths in a browser.
Visiting the /posts
webpage reveals a custom blog featuring the following description:
“The warrior Achilles is one
of the great heroes of Greek mythology. According to legend, Achilles was
extraordinarily strong, courageous, and loyal, but he had one vulnerability
Achilles heel. Homer's epic poem The Iliad tells the story of his adventures
during the last year of the Trojan War.”
At first glance, this content does not
provide direct clues. However, when compared to the homepage, it appears to be
a textual description of the image displayed there. This connection may hold
significance, so further analysis of the content and its context is
recommended.
Inspecting the FlySpray web Dashboard
Now, let’s inspect the flyspray/ webpage.
Upon
visiting, it is identified as the web interface of Flyspray, a
task-tracking system.
Flyspray is an open-source bug tracking system designed for simplicity and ease of use. It provides an efficient way to manage project issues and collaborate with team members effectively.
The presence of Flyspray often suggests a potential
avenue for exploitation, as outdated versions may have known vulnerabilities.
Before diving deeper, we need to enumerate the Flyspray interface for useful
details.
In below, the webpage displays three main
tabs:
Task List
Overview
Roadmap
This Task list tab shows a single task with
the following details:
Category: Backend / Core.
Task Type: Bug Report.
Priority
and Severity: Very Low.
Summary: Bug report.
Status: New
Clicking on the task provides additional
details, which could be useful.
In the comment section below, there is a
comment posted by "Mr. Super User",
which might provide further clues.
About the other 2 tabs:
In the overview, This tab
shows general information about the system, including a summary of Symfonos bugs, with two open tasks listed.
The Roadmap section appears empty, showing
no information about future plans or tasks.
Also, there is a Login button visible in the
top-right corner, indicating the possibility of accessing administrative or
advanced features.
Clicking on it opens a login form requiring a username and password, along with an option to register a new account.
At the bottom-right corner of the interface, the text "Powered
by Flyspray" is displayed.
This information is crucial for fingerprinting
the exact version of Flyspray, which can help identify any known
vulnerabilities associated with the software.
Exploitation
Looking for Potential Vulnerabilities
Although the specific version of Flyspray is not
directly exposed on the interface, a quick search on ExploitDB reveals
potential vulnerabilities. Using the command:
Among these search results, the exploit
listed in the sixth position, targeting Flyspray versions 1.0-rc4,
might be valuable. This exploit could potentially allow us to take advantage of
known vulnerabilities within the application.
Now
that it is saved as a text file, let's open it and examine its contents.
The
file provides basic information about the exploit, outlining its purpose and
potential impact. Let's analyze it further.
SSRF (Server-Side Request
Forgery) vulnerabilities allow attackers to
send crafted requests from a compromised server, potentially accessing internal
systems or escalating the attack. In this case, an XSS (Cross-Site Scripting)
vulnerability in Flyspray 1.0-rc4 can be
combined with CSRF (Cross-Site Request Forgery)
to exploit the system further. This approach could create a new admin account
by leveraging the XSS-to-CSRF method.
Upon reviewing the file, I can determine how it can be
utilized.
Register a New user and verify if is it Vulnerable to XSS
To test for an XSS vulnerability, our first step is to register a new
user.
1. On the login page, click on the Register
button.
2. This action displays a registration form that we need to fill out.
In the Username field, enter a username of your
choice.
In the Password field, input a password. For
this demonstration, I'll use 12345678.
In the Real Namefield, I
will insert a basic XSS script that triggers an alert displaying
"hello" upon successful execution.
Once the form is completed, submit it to register the new user.
3. After successful registration, we can
proceed by logging in with the newly created credentials to verify if the XSS
vulnerability exists.
4. Now, let’s navigate to the user profile page.
5. Upon
navigating, the user profile page triggers a popup
displaying "hello!", which confirms the application is
vulnerable to XSS.
Now that, we know Flyspray to be
vulnerable, let’s serve the exploit script and feed it to the admin account by
changing the Real name into
a script code that will allow us to execute scripts to gather the CSRF token and
submit a form to create a new admin.
Serve the exploit script and feed it to the admin account
1. First, we have to create a file that
containing the exploit code.
You can find the exploit script in the download text file. Copy it
and paste it into a text editor. Save the script with the filename, exploit.js.
2. Now, we need to set up a simple HTTP server to host the
exploit script. Use Python to serve the script: python3 -m http.server
┌──(kali㉿kali)-[~]
└─$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
3. Now, we need to deploy the Exploit.
Modify the Real Name field
of the logged-in user. Input the following payload in the Real Name field:
Replace <YOUR_SERVER_IP> with the IP address hosting the HTTP server.
Navigate to a page where the Real Name field is reflected,
such as in bug report comments or the user profile page.
4. Upon clicking the profile icon, the
embedded exploit.js script in the field will execute automatically.
5. To verify whether the exploit was successful, check
the HTTP server logs on the see lf-hosted Python server.
The logs should confirm that the script was accessed, which indicates it was triggered correctly.
6. Make sure to work properly,It is important to add a comment before updating the details to ensure the exploit executes properly. Adding a simple comment like 'Help!' can help track changes and confirm if the payload triggers successfully.
Re-Login with newly created Credentials
Once confirmed, proceed to logout and re-login using
the newly created credentials:
Username:hacker
Password: 12345678
With a successful login, we now check if the newly created account has any additional information that will lead us to further exploitation. This can be confirmed by accessing the dashboard panel.
Within the dashboard panel, there is a bug report with ID: 2. Reviewing the task description for this report, reveals a hint, which contains credentials. These credentials might grant access to other systems or services within the network.
Upon reviewing the task description associated with this report,
we discovered a hint containing credentials.
With this credential we have we can try to
attempt to gain a foothold on the target system.
Foothold
Access Via SSH
To gain Foothold using the provided
credentials, we will try to attempt to access the system via SSH.
Gitea is a lightweight, self-hosted Git service providing an easy-to-use interface for managing repositories. It is an efficient alternative to GitHub and GitLab, ideal for teams and individuals.
But, what is Gitea?
Gitea is a lightweight,
self-hosted Git service similar to GitHub, offering features such as:
Repositories for version
control
Issue tracking for task management
Code review for collaborative
development
In this scenario, Gitea might be accessible
internally and could contain sensitive information or misconfigurations that
can be exploited.
The focus now shifts to Enumerating Gitea for
potential vulnerabilities or misconfigurations.
Enumerate Gitea
From the Nmap scan, we previously identified a service
running on Port
3000, running a service resembling Gitea, a self-hosted
Git service, which we are looking for enumeration.
Discover details about Exploit 49571 on Exploit-DB, a comprehensive archive of exploits and vulnerabilities for penetration testers and security researchers.
This Python-based exploit allows an
authenticated user to execute arbitrary code on the target system.
By analyzing the exploit script, we can understand how it works and decide to replicate its steps manually to gain a reverse shell.
There are two ways to achieve this —
Modifying an existing repository or
By creating a new one.
Here, let's modify the SymfonOS-blog repository to establish the reverse shell.
But before, we must have to set up a reverse
shell listener using Netcat.
┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4444
listening on [any] 4444 ...
First, click on the repository to open it.
From the SymfonOS-Blog Git Management, locate for Setting.
Then, navigate to Settings, and under the settings menu, select Git Hooks.
In the GitHook we can edit hook files to set up custom operation. Here, we need to edit the pre-receive hook by clicking on the edit icon.
Now, let's inject the reverse shell payload
script into the hook.
Once the payload is added, click on Update Hook to
save the changes.
However, to trigger the exploit, we need to
push a commit to activate the pre-receive hook.
In the Symfonos-blog
repository, let's modify an existing file to push a commit. I'll choose the index.php file
and add a simple comment tag at the end of the PHP code to avoid affecting
functionality.
Click on index.php which will redirect us to the page source code, where we have to click on the edit icon to make some changes.
Next, we have to add some PHP code. To not affect the whole PHP code, I use a comment tag to add a comment.
Next, let's add a commit message to reflect
the changes we've made.
Once the message is added, click on Commit Changes. This action triggers the payload and
initiates a connection to our reverse shell listener.
Before committing the changes, ensure that
the NetCat listener is running to capture the callback.
Once the payload executes successfully, check the listener to confirm an
established connection.
┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.103.3] from (UNKNOWN) [192.168.103.18] 37794
bash: no job control in this shell
[git@symfonos6 symfonos-blog.git]$
Here, we can see in the listener that we
have successfully received a connection and gained a foothold on the target
system.
Enumerate the Session
Now, let's enumerate the session to explore possibilities that may help
us gain full control over the target system.
First, we need to check for the user context
to understand our current privileges. To do this, run the whoami command in the callback session. This will confirm the active user we are operating
as within the compromised system.
[git@symfonos6 symfonos-blog.git]$ whoami
whoami
git
[git@symfonos6 symfonos-blog.git]$
Currently, we have initial access as the git user,
which provides limited permissions. This means we need to perform privilege escalation or lateral movement to achieve full control over the target system.
Now, let's search for user flags.Navigate to the git user’s home directory to check for any user flag.
However, no flag
is found for this user, indicating that there might be other users on the
system, or we may need to enumerate further to gain higher privileges.
Privilege
Escalation
Enumerate System Information
In the privilege escalation phase, our main
goal is to conduct deeper enumeration to uncover potential misconfigurations,
exploitable vulnerabilities, or overlooked permissions that could allow us to
escalate to root or another privileged user. This involves investigating file
permissions, SUID files, running services, and scheduled tasks for possible
exploitation opportunities.
Since we currently operate with limited
user privileges via the reverse shell, we face restrictions in accessing
certain files and commands, making a thorough assessment challenging.
To move forward, let's run the sudo -l command
to check if the git user has any special sudo privileges.
[git@symfonos6 ~]$ sudo -l
sudo -l
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
[git@symfonos6 ~]$
It appears that the git user does
not have permission to run sudo commands. This suggests that other users might
have higher privileges.
Escalate to user, Achilles
Let's change the directory to the /home
directory.
Here, we have identified another user
directory named Achilles, which means there is a user account with this name.
If we recall from the Flyspray post-exploitation phase, we previously discovered a set of credentials.
We attempted to use them via the SSH client, but the login failed, possibly due to key-based authentication requirements or SSH configuration restrictions.
Instead of SSH, let's try switching to the Achilles user by using the su command with the discovered credentials.
[git@symfonos6 home]$ su achilles
su achilles
Password: h2sBr9gryBunKdF9
Now, we have successfully switched to the Achilles user.
whoami
achilles
However, we notice that the shell is limited or hidden. To overcome this, let's
check if Python is available on the system to help us upgrade the shell. If Python’s presence is there, we can run a command to upgrade our shell for better functionality.
python --version
Python 2.7.5
python -c "import pty;pty.spawn('/bin/bash')"
[achilles@symfonos6 home]$
Now that we have
an upgraded shell, let's navigate through the directories to search for a user
flag.
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User achilles may run the following commands on symfonos6:
(ALL) NOPASSWD: /usr/local/go/bin/go
[achilles@symfonos6 ~]$
The output reveals that the Achilles user
is allowed to execute the /usr/local/go/bin/go command as root without requiring a password.
The go command, part of the Go programming language
environment, can be leveraged to execute arbitrary commands or scripts.
Thisprovides a
direct pathway to escalate privileges and gain root access by crafting and
executing a malicious Go script.
Privilege Escalation via Misconfigured Sudo Permissions on Go Binary
First, let's change the directory to the /tmp
directory.
[achilles@symfonos6 ~]$ cd /tmp
cd /tmp
[achilles@symfonos6 tmp]$
Here, we need to create a Go script that will help us gain a root shell when executed. Open a text editor and create a new file.
Add the following code and save it as root_shell.go.
package main
import (
"os"
"os/exec"
)
func main() {
cmd := exec.command("/bin/bash")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
cmd.Run()
}
Now, we need to transfer this script to the
target machine. If you recall, we had already started the HTTP server
earlier to host the JavaScript file used in exploiting Flyspray.
Switch back to the target machine where we
previously navigated to the /tmp directory. Use the wget command
to download the script from our attacking machine.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
