We are blogging to inform you of a recently discovered security vulnerability reported yesterday in FreePBX Ticket 7123 (originally reported in ticket 7117 which is locked because of sensitive information). All FreePBX versions FreePBX 2.9 before 2.9.0.14, FreePBX 2.10 before 2.10.1.15, FreePBX 2.11 before 2.11.0.23, and FreePBX 12 before 12.0.1alpha22 are affected. You should immediately update your FreePBX Framework Module to secure your system from a potential attack.
The vulnerability is a Remote Command Execution (RCE) attack which means a compromised PBX can have any system command executed on it. This may result in serious damage to the system or extraction of passwords and other credentials accessible to the apache user (which is asterisk on most systems).
There were no known exploits at the time this issue was reported but upon going public it is common for hackers to develop scripts to scan the internet in an attempt to find vulnerable systems. The primary attack mode would be blocked on a system that uses HTTP authentication as some Distros set by default. Unfortunately, it is trivial to develop an XSS (Cross Site Scripting) attack that could indirectly access this vulnerability and allow an attacker to get access to any logged in system using all FreePBX authentication options. As such, all systems are vulnerable and should be updated. The fix addresses all attack modes.
(CVE-2014-1903)
Please make sure to update your systems immediately. We informed project teams of the other popular FreePBX Distro's earlier today as well as Certified Hosting Partners.
It appears ticket 7120 may be the first sign of an exploit against this vulnerability. As a result of posting the blog, Mustardman has provided additional logs upon the development team's request that appear to indicate the same attack mechanism. If there is additional helpful information it will be attached to the master ticket 7123 since his ticket 7120, and the original ticket 7117 under which this vulnerability was first reported will remain locked due to sensitive data.
The admin GUI must be accessible, through port 80 unless you’ve configured something different (e.g. https/443) for this attack. Whether or not you have your site protected by a firewall (which is highly recommended), you want to apply this fix.
The Web GUI needs simply to be accessible locally or remotely (e.g. I tested the scenario against my system whose GUI is remotely available through a simple Firewall forwarding rule - the Web GUI external port is not equal to the internal one - and the issue is clearly there however).
The idea that obfuscating the Web GUI by modifying the default listening port number could protect our systems against a well engineered attack is only a temporary palliative (let me using this word); the sad thing is that I know I just used a palliative up to now.
In this case the only remedy to apply ASAP is updating the FreePBX Framework and limiting (that’s always a valid rule IMHO) which IP Addresses (internally/externally) have access to the FreePBX Web GUI.
We regret the few people who had some hiccups because of the FREEPBX-7130 bug that was reported. It appears some previous framework versions had this issue that went un-reported. As a result of this security issues, many more people upgraded which resulted in pulling in those changes as well.
As an FYI, FreePBX primarily codes to a requirement of PHP 5.3 and higher although we have made many efforts to provide compatibility for older versions of PHP for people who do not upgrade their base systems. This makes it a challenge to detect issues like this and we depend on the community to report such issues so we can address them as was the case here as soon as it was reported.
As an FYI:
PHP 5.2 was End of Life 06-JAN-2011 (3+ years ago)
PHP 5.1 was End of Life 24-AUG-2006 (7.5 years ago)
These are the most common versions we encounter when such bugs come up and as you can see, it’s a REALLY GOOD idea to move off of these as there are plenty of known bugs and issues with these older versions. In the words on the PHP Site: “If you are using these releases, you are strongly urged to upgrade to a current version, as using older versions may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP.”
From day-one, we have never exposed any of our FreePBX/Asterisk boxes to the outside except SIP and RTP - We always have them behind a VPN firewall, and to do ANY maintenance on the boxes, you have to first make a successful VPN connection to their network.
Initially it was more of a lack of experience on our part with Linux security, but now after 10 years I still think it’s not a good practice to publicly expose the web interface of these boxes - we have had one instance where the customer screwed up and exposed our box, and we had $4K of toll fraud in the space of 10 hours - there is just too much on the line to lose.
Agreed, you should only allow internet access to the PBX only if there is no other alternative. If this is the case at the very least you should restrict it to certain IPs. I understand there are cases where this is not possible for various reasons but if you are in control you should put yours behind a firewall and VPN in.
As seen in hatredman post above, with the Framework instaled and disabled, after updating it (but leaving disabled), FreePBX presents the module with the 2.11.0.0beta2.2 version again, saying it is disabled but up-to-date, and also saying it is vulnerable. If I click ‘Description’, it says “Description for version 2.11.0.23”.
Following tm1000 directions, enabling the module and updating again solved the issue.
Sofus,
Currently we do not have a mailing list for FreePBX or FreePBX Security Vulnerabilities. All announcements will continue to be made here on the blog and Module Admin also highlights modules with Security fixes.
Hey,
One of the installations i run was affected by this, and the hacker was able to overwrite files and create an account for themselves. How do I deal with this? Is it enough to install a backup of prior to the attack and overwrite all files in /etc/asterisk and /etc/amportal.conf as well as the complete Asterisk database and then upgrade to the current framework version? As far as I can tell, no other files than the ones in /etc/asterisk, /etc/amportal.conf and the database were modified / created by the attacker. So is it save to move on without reinstalling the complete server? And obviously, from now on, freepbx will only be available behind a VPN…
We are blogging to inform you of a recently discovered security vulnerability reported yesterday in FreePBX Ticket 7123 (originally reported in ticket 7117 which is locked because of sensitive information). All FreePBX versions FreePBX 2.9 before 2.9.0.14, FreePBX 2.10 before 2.10.1.15, FreePBX 2.11 before 2.11.0.23, and FreePBX 12 before 12.0.1alpha22 are affected. You should immediately update your FreePBX Framework Module to secure your system from a potential attack. 
