1. Intro
The Asterisk PBX and more specifically the Asterisk web-based provisioning GUI interface often stands as a primary target during a Penetration Test, due to its promising potential in case of compromise.
During this case-study we will be focused on Trixbox CE which is the Community Edition of Trixbox (formerly Asterisk@Home), an easy to install VOIP phone system based on the Asterisk PBX. Trixbox CE is a completely free and open-source software available under a GPLv2 license with over two million downloads as of August 22, 2009.
It is important to note that in October 2012, Fonality announced that they would no longer support and/or update Trixbox CE, and would instead focus on Trixbox Pro, the commercial version of Trixbox.
2. Trixbox CE 2.8.0.4 Exploitation: From Zero to Herο
2.1 Installation and Lab Setup
In order to perform the assessment against Trixbox CE, we installed the latest version of Trixbox CE v2.8.0.4 ISO [1] on a virtual machine, which is available for downloading via SourceForge.
Trixbox CE’s core technologies include:
- The Linux distribution on which Trixbox CE is built (i.e. CentOS).
- Asterisk which provides the core PBX functionality.
- FreePBX which provides a web-based provisioning GUI interface for managing and configuring Asterisk through a web browser.
- Flash Operator Panel (FOP) which provides a graphical overview of current calls and provides controls to operators.
After the successful installation of the Trixbox CE v2.8.0.4 ISO on a virtual machine on our lab, we logged in to the Trixbox CE web-based provisioning GUI interface, using the default administrative credentials “maint:password”.
2.2 Identification and Exploitation of CVE-2020-7351
Through the main administrative menu, we navigated to a functionality (“PBX -> End Point Configuration”) which maps network devices on a user-defined subnet.
After couple of tests, it was identified that the remote application is vulnerable to authenticated OS command injection attacks (inclusive in the “network” POST parameter of the “endpoint_devicemap.php” page), which arise when an application incorporates user supplied data as arguments of a command that is executed on operating system level. Due to that fact, a potential attacker may leverage this vulnerability and execute arbitrary commands on the underlying operating system, resulting to potential takeover of the host.
As shown on the following demonstration, by using a specific payload a potential attacker could be able to execute arbitrary commands on the underlying operating system containing the user-supplied details such as:
- ;$(sleep 15) :Through which the application’s response delays 15 seconds to return data.
After that, we fired the commix tool [2] and we managed to exploit the identified authenticated OS command injection vulnerability, which allows for arbitrary command execution on the underlying operating system as the “asterisk” user.
2.3 Privilege Elevation
Strangely enough, it was identified that the Elastix has the following entries in its “/etc/sudoers” file which means that since Nmap is in the list of binaries that could be executed with root privileges it is possible to use the interactive console in order to run a shell with the root privileges.
Finally by abusing the Nmap’s interactive mode we escalated our privileges (i.e. “asterisk” user) to root privileges:
2.4 Extra Mile (the Metasploit Module)
Nevertheless, as a POC (Proof-of-Concept), we developed a Metasploit module [3] for CVE-2020-7351 [4], that exploits the authenticated remote code execution (RCE) in the “endpoint_devicemap.php” page of Trixbox CE devices running version 1.2.0 to 2.8.0.4 inclusive.
Recommendations
After the successful exploitation of the identified authenticated OS command injection vulnerability we pointed the vulnerable part of the code in “endpoint_devicemap.php” page that incorporates user supplied data (i.e. via “network” POST parameter) as arguments of a command that is executed on operating system level:
Since user input – as a principle – should be considered as non-trusted, it is highly recommended to perform effective validation on the user input. The validation algorithm should allow only the characters included in a whitelist, explicitly defined by the business needs of the application. Moreover, all characters identified as dangerous (‘,”,(,),{,},[,],;,-,+,=,-,%,&,*,#.<.>,/,\), whitespaces, or other syntax should belong to a blacklist that will enforced after the initial whitelist check.
References
