I was made aware of a new zero-day FreePBX exploit today - apparently it affects Phone Apps, even if you’re not using Phone Apps in a licensed capacity.
Does anyone have any information on this? Apparently, and earlier post on the subject was pulled down? Do we have any sort of statement from Sangoma or an ETA for a security fix? Should we be closing down the public facing Phone Apps port for all customers?
Can the affected versions be pulled from the mirrors? Looks like they can still be downloaded. Not sure how practical/possible this is without breaking other things…
Also just to note I could not find 22.214.171.124 in the repository, however I was able to grab 126.96.36.199.
[[email protected] ~]# fwconsole ma downloadinstall restapps --tag 188.8.131.52
No repos specified, using: [standard] from last GUI settings
Unable to update module restapps - 184.108.40.206, it does not exist:
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 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?
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.
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.
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.
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.
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.