FreePBX has been around for decades, and was one of the three popular Asterisk GUI's and our choice for years. Asterisk itself has been around longer, and we've been providing and supporting it since version 1.6. That aside, FreePBX has been constantly developed and enhanced with functions and features providing a framework to build an asterisk dial plan configuration with a nice GUI interface. FreePBX provides include files that can be leveraged to add custom dial plans whilst maintaining general management via the GUI.
Up until 2015, FreePBX was in a constant development cycle providing regular updates, fixes and features primarily provided by Schmooze, a wisconsin based developer who provided very good commercial support and some commercial modules to monetise the operation. These commercial modules could be purchased with a 25 year license (mostly) and for many this was a great way to get some great commercial features for a sensible charge.
In January 2015, Sangoma acquired Schmooze and from this point onwards, development slowed, updates slowed and commercially licensed modules stopped updating. Today, development on FreePBX seems to slowed significantly, and even the blog postings on freepbx.org have stopped. Sangoma are still selling the same modules and support but I hazard a guess that their commercial SwitchVOX product is taking priority which is a shame.
Back to the title, We were investigating a data breach at a company (not an existing customer) and working backwards from the epicentre, which was their MySQL server back to the source. We had already identified that the MySQL Server login had been 'discovered' and leveraged to select data from a range of tables from the FreePBX box. We removed the FreePBX Box, imaged it and then returned it. Analysing the image we could see some activity with the mysql -u command under the root login accessing the company's remote MySQL Server.
I won't bore you with the nitty gritty of the FreePBX box compromise, but let's just say that it was running PHP 5 on Centos 6.5 as the majority will be, simply because the upgrade path is fraught with issues. The backup/restore function does most of the job but there will almost always be some manual correction or even a fresh install and reconfigure which dissuades operators from this path unless absolutely critical. Combine this with the relatively complex setup of NATted SIP/RTP and this promotes the bad practice of putting FreePBX on the dirty side of firewalls, which this was.
Once the FreePBX box was compromised, there were numerous opportunities to pillage the configuration for upstream SIP credentials (stored in the clear) as well as extension and voicemail passwords, voicemail's, and other data. The hacker had created an inbound route on the switch directing a DDI call to a DISA endpoint, allowing them complete system access. There was also evidence of numerous reconfigurations of inbound routes for unknown reasons. I fully expected the hacker to create or compromise an extension, pretend to be 'IT' and then leverage credentials out of the staff, but instead they simply dumped the asterisk database and found the MySQL Server credentials stored in the clear in the superfectaconfig table. Superfetcha is a module that, when given a CID is able to pull info from various sources (as plugins) and use that to influence the CallID information passed through to the endpoint. It's not a bad module, it works and it's not the authors fault that it stores passwords in the clear (although there are other more secure options such as 2 way TLS), but the clear risk here is that any credentials you enter into it can be retrieved fairly easily and exploited.
For this customer, their MariaDB database contained their customers, contacts, quotes, invoices, contracts and pricing, all of which was sold on. This breach was highlighted by one of their competitors picking up the phone and notifying them that they were offered the data for a very moderate fee, which was a very honest and professional thing to do.
VoIP servers are often overlooked by risk managers as they are thought to be 'isolated' from the things that matter, but as we can see in this specific case, a simple CID Lookup provided everything needed to compromise the main database server and export it all. I know some may comment that the MySQL login should have been restricted to a certain table or view, but in reality that just doesn't happen that often in the wild and even if a DBA created a view, a user restricted to the PBX box, and granted it select only on that view, you've still given the would-be hacker a valid and operational login to your MariaDB/MySQL database that could be exploited. ANY authenticated connection between server A and Server B creates a possible route for compromise, and you should consider carefully the risk and reward of each.
I'm not sure what the future holds for FreePBX in the hands of Sangoma. We could see a community supported fork much in the ways of MariaDB, or Sangoma could re-ignite development and clear some of the 802 open issues, we hope so.
IF YOU ARE RUNNING FreePBX and don't have an active support agreement then get one and ensure...
If you want to be really comprehensive in your network security policy, then segregate the FreePBX box between two firewalls creating a VLAN for it. This way you have SIP, RTP and IAX NAT'ed to the internet and your upstream providers with specific firewall rules allowing traffic to and from those providers ONLY. The internal LAN firewall will allow only SIP/RTP traffic to and from the FreePBX box and the network segment with your IP phones on it, and HTTP(s) traffic to the network segment with your users on it. Everything will work just fine but with some extra hardware (or even using iptables/firewalld) you've reduced the possible paths to compromise to a negligible level. Anything that talks to the outside allowing incoming connections, even if its just your VoIP Server is a risk that needs to be managed, and this isn't just a FreePBX issue, FreePBX is quoted here simply because this was the route to compromise in this case, but any VoIP server has the same risk factors and should be equally considered.
If you found this interesting, comment and/or Like. If you need help and advice on your FreePBX server then use the forums for free community assistance or the HelpDesk for priority support.
"In January 2015, Sangoma acquired Schmooze and from this point onwards, development slowed, updates slowed and commercially licensed modules stopped updating. Today, development on FreePBX seems to have completely stopped, and even the blog postings on freepbx.org have stopped. Sangoma are still selling the same modules but this time for an annual charge and of course selling 'commercial' support. We provide commercial support for FreePBX too, but we do it cheaper and we don't make you buy 'credits' beforehand. "
There are so many inaccuracies in this paragraph alone-- this article shouldn't have made it to published state. Development is ongoing, I see it every day. Did you even care to look at the Sangoma Issue Tracker? The FreePBX community forums? Could you even be bothered to ask anyone? This is clickbait at best and outright lies at worst.
Thank you Brian L for your thoughts. I didn't write the article but I did see a draft about a week ago and re-reading it today I think its fairly accurate, but I will address your comment directly.
FreePBX DEVELOPMENT has stagnated in the hands of Sangoma, and I see this every day, as Jon said there hasn't been a new module or note worthy feature for a long time and on top of that we're seeing historically functional modules being no longer available online and available to new systems. This is no surprise to anyone, its just business. With Sangoma now selling SwitchVOX why on earth would they put time and money into an open source competitor?
I did take a look at the issue tracker, and it shows 804 open issues, so thank you for highlighting that for us.
The Forums are, as Jon said full of people trying to get help for issues. We support just under 600 switches on maintenance, and most of these were migrated to FreePBX in the past from elastix, fonality, etc but for anyone who doesn't use FreePBX internally we're pulling it out and rebuilding the dial plans manually simply to reduce risk, increase performance and improve security. The WHOLE POINT of this article was to highlight an issue we recently discovered in an audit and to make people aware so they can secure their box.
I get that you are obviously a FreePBX fan and that's great but storing database passwords in the clear is unforgivable in the 21st Century!
That may be your opinion but as a FreePBX user I think its fairly accurate. I cannot remember the last time we had a new module or feature worth mentioning and the community forums mostly people with issues trying to get some help. I like FreePBX and its clunky 90's interface but what I didn't know and what was highlighted in this article was that it stores important passwords in clear text!! I know someone is going to comment that its open source and if I'm not happy then go fix it myself but I am not a programmer. I found the article interesting and it made me think about securing the server which I'm doing today.
I think the market is consolidating and with commerical options like 3cx offering 25 user foc and sangoma actively promoting switchvox to freepbx installs its about done. we had freepbx for years but migrated to 3cx about a year ago and are very happy with it. There r other open pbx's up and coming like fusion but i think the market will move small business to free or budget commercial systems and open pbxs will be left for home users etc.
for storing passwords in the open thats really bad and needs to be highlight so people can remove them and make the box safe.