TryHackMe Billing Room: Command Injection to Root Guide
Explore the Medium-difficulty TryHackMe Billing room, exploiting IcePay command injection and leveraging Fail2Ban for full root privilege escalation.
Stock photo for illustration only, not from the actual event
- Target is the Billing room, a Medium-difficulty challenge on the TryHackMe platform.
- Initial foothold achieved via an unauthenticated command injection in the IcePay module's democ parameter.
- Privilege escalation performed by abusing fail2ban-client sudo rights to rewrite the actionban command.
- System built on MagnusBilling running over Asterisk PBX with a MariaDB backend.
The Billing room on the TryHackMe platform, rated at a Medium difficulty, immerses security enthusiasts into a specialized telecommunications architecture. The environment features MagnusBilling, an open-source billing software operating on top of the Asterisk PBX service, backed by a MariaDB database. This infrastructure offers a unique attack surface extending beyond standard content management systems, encompassing payment gateway integrations, call manager ports, and a telephony-backed billing panel.
The assessment begins with a port scan conducted via rustscan targeting IP address 10.49.178.53, revealing key services including port 22 (SSH OpenSSH 9.2p1), port 80 (Apache 2.4.62 running MagnusBilling), port 3306 (MySQL MariaDB 10.3.23), and port 5038 (Asterisk Call Manager 2.10.6). Running Feroxbuster against the web root maps out the complete MagnusBilling installation structure, uncovering directories for various payment gateways such as icepay/, mercadopago/, stripe/, anet/, and PlacetoPay/.
Since payment gateway code is typically maintained by external teams and undergoes less rigorous security reviews than core application components, it presents an ideal entry point for vulnerability discovery. Examining the IcePay integration file icepay.php reveals that the democ parameter accepts input and passes it directly into a shell execution context without validation, allowing unauthenticated attackers to append shell metacharacters and execute arbitrary commands.
This vulnerability highlights a classic real-world security pitfall where third-party plugins or payment modules are bolted onto core applications with less stringent oversight. The lack of proper input sanitization directly leads to command injection flaws, emphasizing the critical need for developers to thoroughly validate all external parameters.
Exploiting this flaw using Netcat to catch a reverse shell grants access under the asterisk system user account, which runs the Asterisk and MagnusBilling services. Users can then retrieve the standard user flag located at /home/magnus/user.txt, yielding the hash THM{4a6831d5f124b25eefb1e92e0f0da4ca}.
Stock photo for illustration only, not from the actual event
The privilege escalation phase initiates by running sudo -l, which discloses that the asterisk user is permitted to execute /usr/bin/fail2ban-client without requiring a password (NOPASSWD). Fail2Ban functions as a log-monitoring daemon designed to detect malicious activities and block offending IP addresses by implementing firewall rules.
Although the original configuration files under /etc/fail2ban/action.d/*.conf are write-protected against modification, fail2ban-client allows administrators to redefine jail actions live directly from the command line. By modifying the actionban setting for the sshd jail, an attacker can configure a malicious curl payload to execute upon a ban trigger.
Triggering the ban condition manually against the loopback address 127.0.0.1 for the sshd service forces Fail2Ban to execute the newly configured actionban command. Because Fail2Ban operates with administrative privileges to manage firewall rules, this execution grants a full root reverse shell, allowing retrieval of the final flag at /root/root.txt with the value THM{33ad5b530e71a172648f424ec23fae60}.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment