Billing
Some mistakes can be costly.
Recon
Our initial Nmap scan reveals four open ports, including a web server running on port 80, a MariaDB service on port 3306, and an Asterisk Call Manager on port 5038.
The default script scan also reveals the contents of the robots.txt file, which includes a disallowed entry for the /mbilling directory.
Upon visiting the directory, we are presented with a login page. Additionally, the title of the page displays the name MagnusBilling.

A quick search reveals that MagnusBilling is an open-source VoIP billing and management system. It is designed for managing SIP trunks, VoIP calls, and customer billing, offering tools for call routing, monitoring, and invoicing.
Initial Access
MagnusBilling is affected by an unauthenticated remote command execution vulnerability, identified as CVE-2023-30258. This vulnerability can be exploited manually, but it is also available as a module within the Metasploit Framework.
The exploit succeeds, granting us a shell with the privileges of the asterisk user.
While exploring the system, we find another user, magnus, listed in /etc/passwd. We have access to their home directory and successfully retrieve the user flag from there.

Privilege Escalation
As the asterisk user, we can run sudo -l without a password, revealing that we have permission to execute /usr/bin/fail2ban-client with root privileges.
Fail2Ban is a security tool that monitors log files for suspicious activity, blocking IP addresses after multiple failed login attempts. It helps prevent brute-force attacks by automatically applying firewall rules.

The following resource offers various techniques for leveraging Fail2Ban to escalate privileges, potentially allowing us to gain root access.
There's an approach where you can customize a config in the config directory and place code in it to be executed with root permissions. Unfortunately, we only have read-only access to the directory and its contents.

We can work around this limitation by copying the configuration directory and referencing it when executing fail2ban.
In the fail2ban-client command, the -c option allows us to specify the configuration directory for Fail2Ban.
Using the command
we recursively copy the contents of /etc/fail2ban/ to /tmp/fail2ban/.
We can follow the Exploiting Fail2Ban and Getting a Root Shell section from Juggernaut Sec to customize action.d/iptables-multiport.conf and restart the service, or alternatively, create our own configuration.
In this case, we write a custom configuration that executes a script, which then copies /bin/bash to /tmp/bash and sets it as a SUID binary, allowing us to obtain a root shell.
After running the script, we have a SUID binary located at /tmp/bash. By executing it with the -p parameter, we gain a root shell. From there, we find the root flag at /root/root.txt.

Last updated
Was this helpful?
