FreePBX as a route to a Data Breach

The History

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 have 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. 

The Breach

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. 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. Superfecta 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. 

The Risk

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...

• It's running the latest version of FreePBX.
• It's running on a recent version of Linux and up to date.
• It's behind a firewall with SIP/IAX NAT'ed & firewalld is setup and configured.
• Apache is restricted to the LAN.
• Do NOT give CallerID Superfecta or CIDLookup credentials to your database server. If you MUST use caller ID lookup then
  • Either push a limited table of data to the FreePBX server's MariaDB database and query it there.
  • Or use an API to do the lookup, which you may have to write so it can only pull a customer given a CLI
  This is not hard to do and once setup will function just the same as a remote lookup but will maintain that isolation between the FreePBX box and the company database(s). 

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 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 hit the HelpDesk. 

Blog Index   PermaLink   Comment           6 Votes  

Comments (2)