Hacking VOIP Web Applications | MagnusBilling | TryHackMe Billing Walkthrough

This article explores how VOIP web applications, specifically MagnusBilling, can be exploited using simple command-line techniques. This video also provides the answers for TryHackMe Billing room.

Introduction to VOIP Web Application Hacking

The article discusses how VOIP systems, particularly web-hosted applications, can be compromised using simple command-line techniques. The TryHackMe challenge on MagnusBilling is used as a real-world example of how penetration testers and hackers can exploit these systems.

Initial Reconnaissance with Nmap

We begin with an Nmap scan to enumerate open ports and services running on the target machine. The scan reveals three open ports, indicating the presence of a web server and an Asterisk Call Manager running on port 5038.

By using different scan speeds (dT4 vs dT1-dT3), we optimize the scan to reveal additional ports while avoiding detection from intrusion prevention systems.

Enumeration of the Web Application

We investigate the MagnusBilling login page. Using manual techniques such as viewing the page source, checking GitHub repositories, and searching for configuration files, we determine the exact version of the billing system.

Knowing the version is crucial because it allows the hacker to look for known vulnerabilities related to that specific release.

Identifying Vulnerabilities in MagnusBilling

By searching for public CVEs, we find that MagnusBilling v6 and v7 are vulnerable to command injection. This vulnerability allows unauthenticated users to execute arbitrary operating system (OS) commands on the server.

We focus on a specific file (icepay.php), which contains a direct call to the exec() function, making it a prime target for injection attacks.

Exploiting the Command Injection Vulnerability

We test the vulnerability by sending a GET request with a malicious payload. The initial test involves injecting a simple sleep command (sleep 20), and since the response is delayed, it confirms that commands are being executed on the server.

Further exploitation involves executing more complex commands to interact with the file system and gain deeper access.

Obtaining a Reverse Shell

To gain persistent control over the machine, we establishe a reverse shell using Netcat (nc). The process involves:

1. Identifying the attacker’s IP address for the connection.
2. Crafting a payload that launches a shell and sends it back to the attacker’s machine.
3. Setting up a Netcat listener to capture the shell connection.

Once connected, we can execute system commands remotely as the low-privileged web server user (www-data).

Privilege Escalation Using Fail2Ban

We look for ways to elevate privileges from www-data to root. We find that the Fail2Ban service is running as root, making it a perfect target for privilege escalation.

We modifie Fail2Ban’s configuration files (jails) to execute arbitrary commands instead of their intended security functions. By triggering the modified Fail2Ban rule manually, we successfully execute commands as root, allowing them to take full control of the system.

Root Access Achieved & System Compromise

We verify that the UID bit has been set on /bin/bash, granting them full root privileges when executing the shell. By launching a new root shell, we can now read sensitive files, modify system configurations, and complete the hacking challenge.

We retrieve both the user and root flags, successfully compromising the system.

Insights Based on Numbers

• Three Open Ports Identified
  • The attacker initially found three open ports using Nmap, which led to the discovery of a vulnerable web application.
• 20-Second Sleep Delay Confirms Injection
  • The hacker confirmed the command injection vulnerability by making the server sleep for 20 seconds using a crafted HTTP request.
• Eight Active Jails in Fail2Ban
  • By inspecting Fail2Ban’s security jails, the attacker found eight configured jails, which allowed them to manipulate one for privilege escalation.
• Root Shell Access Achieved in Under 700 Seconds (~11 Minutes)
  • From initial scanning to full root control, the entire attack was executed in less than 12 minutes, demonstrating how quickly a system can be compromised.

TryHackMe Billing | Room Answers

What is user.txt?
THM{4a6831d5f124b25eefb1e92e0f0da4ca}

What is root.txt?

THM{33ad5b530e71a172648f424ec23fae60}

Video Walkthrough

How Can Financial Web Applications Mitigate Risks Associated with Command Injection Vulnerabilities?

Financial web applications are prime targets for cybercriminals due to the sensitive financial data they process. A command injection vulnerability, like the one demonstrated in the MagnusBilling attack, can allow an attacker to execute arbitrary system commands, leading to data breaches, financial fraud, and complete system compromise. Below are key mitigation strategies to prevent such vulnerabilities:

1️⃣ Input Validation & Sanitization

• Always validate user input before processing it. Ensure that input conforms to expected formats (e.g., only numbers for IDs, specific character sets for names).
• Use whitelisting instead of blacklisting. Accept only known safe inputs rather than trying to block malicious ones.
• Sanitize user input by stripping out potentially dangerous characters (;, &, |, etc.) that could be used in injection attacks.

Use Parameterized Queries & Prepared Statements

• Instead of dynamically constructing system commands with user input, use safe execution methods such as:
  • Prepared statements for database interactions (e.g., in SQL queries).
  • Secure shell execution libraries instead of raw command-line calls (exec(), system(), shell_exec(), etc.).
• Example in PHP (safe execution):

$command = escapeshellcmd("ls -la /var/www");
$output = shell_exec($command);

This ensures user input does not modify the intended command structure.

Least Privilege & Role-Based Access Control (RBAC)

• The web application user (www-data) should have minimal system privileges.
• Restrict access so that:
  • Web applications cannot execute arbitrary system commands.
  • Only necessary processes are allowed to run.
  • Privilege escalation techniques (e.g., sudo access) are strictly controlled.

Secure Software Development Practices

• Avoid functions that execute system commands, such as exec(), system(), shell_exec(), and popen().
• If shell execution is necessary, use safe APIs like:
  • proc_open() with controlled execution.
  • Symfony Process Component (for PHP applications).
• Always escape arguments properly to avoid shell injection.

Web Application Firewalls (WAF)

• Deploy a Web Application Firewall (WAF) to detect and block malicious input patterns.
• A well-configured WAF can help prevent common command injection attempts by blocking suspicious requests.

Regular Security Audits & Code Reviews

• Conduct static and dynamic security testing (SAST & DAST).
• Use tools like:
  • Burp Suite – for web vulnerability testing.
  • OWASP ZAP – for automated security scanning.
  • PHPStan or SonarQube – for static analysis.
• Regularly review logs for anomalous activity that may indicate an attack attempt.

Patch Management & Software Updates

• Ensure that all software components (billing applications, libraries, OS) are up to date.
• Apply security patches promptly, especially for known vulnerabilities (e.g., CVEs).
• Subscribe to security advisories to stay informed about new vulnerabilities.

Logging & Monitoring

• Implement real-time monitoring and logging mechanisms to detect unusual system behavior.
• Use SIEM (Security Information and Event Management) systems to track logs for signs of exploitation.

Use Secure Configuration Defaults

• Disable unnecessary system features (e.g., shell access for web users).
• Configure file system permissions properly to prevent execution of unauthorized scripts.
• Harden PHP/Apache configurations:

disable_functions = "exec, shell_exec, system, popen, passthru"

Conclusion: Defense-in-Depth Approach

To prevent command injection and secure financial web applications, organizations must adopt a multi-layered security approach that includes input validation, secure coding practices, least privilege access, and continuous monitoring. By proactively implementing these best practices, businesses can minimize their attack surface and reduce the risk of exploitation.