0 Day FreePBX Exploit?

You can access restapps through normal http/https ports non specific to the restapps ports themselves (eg port 80 and 443 respectively) because of this blocking traffic to the restapps ports will not protect you unless you block access to all http/https traffic.

Source: I worked with @billsimon on the original POC (Proof of concept) for this new exploit in the now removed (for security not obscurity) thread. My POC worked against admin http/https (80,443) along with the restapps ports. @billsimon and I have been working with Sangoma (@mattf, @lgaetz and @mbrooks respectively). The original attack itself centered around exploiting restapps through the admin interface on https.

Tr;dl, You aren’t getting around this by blocking only the restapps ports. Downgrading the modules as suggested is the only way to prevent being hacked.


Can we disable Phone Apps if we’re not using it, or uninstall/Remove?


fwconsole ma delete restapps
fwconsole reload

Can we get some clarification on this because Ward is over on the voip-info forums saying that this has to do with the freepbx_ha module and a license being triggered. Is this the case? Because then if they need to use freepbx_ha wouldn’t those without that installed (during the OS install) be fine? Or is this a double whammy thing?

As I pointed out last week, the HA module seems to be gone from the mirrors and throws a bunch of errors after I moved systems from 13 to 14. Can’t remove the HA module normally because it can’t be verified since it doesn’t exist in any place the system verifies things.

I do have, what I think, is a serious question. Since the modules being mentioned here are commercial which means only Sangoma developers work on them.

How did a ZERO DAY exploit from almost TWO years ago end up regressed into new updates? This seems like an important thing to pay attention to and not have regression on. Why is QA and testing still a very weak part of this project in 2021 and over a decade into it?

Sangoma will comment in full shortly.

Originally I thought it was freepbx_ha but the exploit in question only masks itself using freepbx_ha after the entry point. So removing ha or disabling it doesn’t really matter because the entry point is the same. Of course Wards comments about this are before the discussion went internal between myself @billsimon and others at Sangoma so Ward only has a view of the first 20 minutes of discussion on this when in reality the discussion went on for another 3 hours.

What this means is freepbx_ha is rather irrelevant. The entry point is the same and is not frrepbx_ha. It would be trivial for another exploit to use the same entry point but mask itself as a completely different module.

In fact according to research @billsimon did you don’t even need freepbx_ha on the system at all.

I want to give Sangoma the opportunity to comment in full so I’m trying to not reveal too much information but I think it’s important some questions are answered so that people don’t feel like “well I don’t have freepbx_ha so I am fine” because that’s a false sense of security. You aren’t fine.

The same way that the updateall function keeps getting regressed to install apps that are not installed.
The same way that usermanager was eating processes and instead of fixing it properly they dumped it to a cron.
The same way said cron was implemented bad and filled up everyone’s inbox over the weekend.

Because there is no QA.


Just like there is no spoon?

1 Like

Hey Tom,

The long and the short of it is that there were some changes that were made in the restapps module recently that were trying to fix a few bugs in phoneapps usage with phones in funny network environments - one of the more recent changes caused this regression.

We did not previously have a unit test written around this particular exploit (mostly due to the fact that there were some significant challenges around unit testing the code due to its former architecture). After this though, we’re going to be dumping a bunch of time into refactoring that code to make it more unit testable and so we can include a test case to cover this and any other similar issues that may come up in the future.

Big apologies again for the trouble around this.

1 Like

Matt, I’m just going to be brutally honest here. I will need to look at the v16 code but everything code wise that I have looked at up until 15 is a frigging mess. There is zero consistency in the coding standards so I’m pretty sure that can have an impact on things.

I mean let us take your Asterisk counterpart as an example. If I look at the code for something I cannot tell that 6 developers have touch the code because it is consistently the same through out. Comments, formatting, structure all the same. On the other hand when looking at FreePBX code you can tell multiple people have touched it because there is zero consistency through out the code. Some of it is formatted in actual readable and logic ways, some may have comments and my favorite is the developers that insist on writing PHP code like JQuery/Javascript with all the code minified in to a few lines with no spacing or readable formats.

So talks about unit tests being written or other such things worries me due to the lack of actual coding guidelines and practices that I’ve seen through the project.

1 Like

Coding and uniformity standards as well as testing info is all documented. They simply aren’t enforced.

At new ventures all of this is enforced with ci. We use static analysis etc and nothing can mainline without passing

Thanks for your honest feedback Tom.

I think as a project we’re trying to move things in a direction where we have a bit more consistency as far as code styles and consistent best practices go. As new contributions go through the code review process, we welcome any and all positive participation in helping with those goals.

Separately from that, automated testing is an area that we have reaped great rewards from on the Asterisk side to provide significant comfort and stability to its code base. It is a personal interest of mine to bring those benefits to FreePBX as well.

Best wishes,
Matthew Fredrickosn

On the OP topic

I mean, I’ve been complaining/speaking out about the coding standards since pre-2019. So you’re saying they’ve existed all this time and no one has ever enforced them? Because having a full time Sangoma QA Team was something flexed about in 2017/2018 because it didn’t exist before.

This now makes me wonder how long this project has had policies and procedures in place that have been ignored and not enforced at any level of the hierarchy.

speaking of, that post links to a wiki article that says little, but links to this bug report that has apparently been hidden.


Why post such a report then? Just make it a FREEI that none of us can ever see anyway as it was a commercial module vulnerability anyway.

This was the bug ticket I filed, which had to be a “FREEPBX”

1 Like

James came up with those standards and wrote them into the wiki before we were able to have a devcon again together to discuss. They were never discussed at length but they do exist in the wiki yes.

Freepbx itself was created in the php 4.x era of time. Well before php itself had standardization. Or PSRs or even static analysis tools. The php of today is vastly different from the php when freepbx started. Or even the php of 2009 when I found and started contributing to freepbx. There were no standards then from the people running freepbx.

No standards were enforced throughout my time at Sangoma (either from me or others). Should they have been. Yes definitely. But they weren’t.

I assumed.

My point was why even post that in the wiki if it is not going to be public.

Some effort needs to be done to sanitize things before the ticket can be opened to public.