Billing
Some mistakes can be costly. - by RunasRs
The following post by 0xb0b is licensed under CC BY 4.0
Recon
We start with a Nmap scan and find four open ports. Among them, we have a web server on port 80, a MariaDB service on port 3306 and an Astersik Call Manager on 5038.

From the default script scan, we can also see the content of robots.txt, which has a disallowed entry for the /mbilling directory.
We visit the directory and have a login page in front of us. Furthermore, we can see the name MagnusBilling in the title.

After a short search, we see that it seems like an open-source VoIP billing and management system for managing SIP trunks, VoIP calls, and customer billing. It provides tools for call routing, monitoring, and invoicing.

Shell As asterisk
This has an unauthenticated remote command execution vulnerability CVE-2023-30258, which is available as a manual exploit but is also present in the Metasploit framework.
We set up the exploit in the Metasploit framework and give it a try.
We get a shell and are the user asterisk.

We set up another listener, and set up another reverse shell. Due to the fact that I am not so familiar with the Metasploit framework and would like to have an upgraded shell.
To upgrade the shell, we follow the instructions provided here:

We find another user, magnus in /etc/passwd. We have access to the home directory of the user and can read the user flag here.

Shell As root
As asterisk, we have the permission to execute sudo -l without password, and we are allowed to execute /usr/bin/fail2ban-client with root permissions.
Fail2ban is a security tool that monitors log files for suspicious activity and blocks IP addresses after repeated failed login attempts. It helps protect servers from brute-force attacks by automatically adding firewall rules.

The following resource provides various insights into how this could be used to extend your privileges.
There you can find an approach to customize a config in the config directory and place code in it that is to be executed with root permissions. Unfortunately, we only have read-only access to the directory...
... and its contents.

But we can remedy this. We can copy the configuration directory and refer to it when executing fail2ban.
In the fail2ban-client command, the -c option specifies the configuration directory for Fail2Ban.
With rsync -av /etc/fail2ban/ /tmp/fail2ban/ we recursively copy the contents of /etc/fail2ban/ to /tmp/fail2ban/.
We can then follow the Exploiting Fail2Ban and Getting a Root Shell section from https://juggernaut-sec.com/fail2ban-lpe/ and customize action.d/iptables-multiport.conf and restart the service or write our own config.
With the following, we write our own config, which executes a script, which in turn copies /bin/bash to /tmp/bash and makes it a SUID binary to get a root shell.
After running the script we have a SUID binary at /tmp/bash and can execute it with the -p parameter to get a root shell. We then find the root flag at /root/root.txt.

Last updated
Was this helpful?
