@lgaetz Thoughts on this?
(2) DEF CON 31 - Calling it a 0 Day - Hacking at PBX UC Systems - good pseudonym - YouTube
So the guy reports some serious 0 day stuff and Sangoma never discloses it to the users and never properly fixes it. SHOCKED.
1 Like
And some of those apparently unfixed reports go back as many as 13 years. If this guy can get easily get root, my guess is that the ‘scriptkiddies’, so often derided here, in eastern europe and the far east have also done that.
2 Likes
Yeah and the API RCE that was found for the generateDocuments() function was introduced, verbatim code, by tm1000 back in April 2018. That function doesn’t look to have been touched since it was introduced with that commit back in 2018. It would make one believe that this RCE is at least 5 years old and not a single developer or QA tester found this exploit within Sangoma.
As for the other ones that were talked about in that seminar, they are all commercial based modules which are not only obfuscated but code repos for them are hidden from the public. So no one can go in and find, like the aforementioned exploit, that it has been sitting in the code for X years and not a single person at Sangoma found it.
The fact that Sangoma has been overly mum on this is a serious problem. However, the fact these RCE’s appear to have been just sitting around for years and not a single developer or QA person was able to find them or why the developers were making such mistakes is something that has been an ongoing issue at Sangoma since it took stewardship of this project.
Along with the patch that was released to fix some (or all) of the issues brought up in the seminar also failed to work once again shows that the policies and procedures in handling the development of FreePBX are flawed and have been for a long time over various teams. This is something I had mentioned to Nenad back in 2020 during a conversation about the development of the project. I pointed out that whatever was in place up to that point really need to be addressed, fixed and overhauled because it was resulting in issues that didn’t need to even exist.
I mean really this isn’t a new problem, we’ve been done this road quite a few times since the v13/Sangoma era started. At some point though, someone needs to realize the bus is on a very bad road and needs to find a new road. Otherwise, people are going to start wanting to get off the this bus and find one that is more smooth going.
4 Likes
Quick update from our point of view …
FreePBX Engineering received the four issues in a single report on the timeline as stated in the video. Internally, three of the issues were grouped together as low risk, as the exploit requires successful PBX administrator login in order to leverage them. Updates for the relevant modules were published to edge in May and ultimately promoted to the stable repo in late May/early June. The reporter was made aware of the published updates to resolve the reported issues, and did not share any further findings with us. From the video I learned that we need to check the API module issue further which is underway now.
The fourth issue was more serious. If the Phone Apps web port is exposed to untrusted traffic, as it could potentially allow a malicious user to brute force access to freepbx internals. The fix for this issue was published as a security update on 2023-09-05. All PBX admins on currently supported versions would have gotten dashboard and email notifications of the available update at that time. For systems that have enabled the option to auto install security updates, the dashboard notice would look like:
Wiki page for this issue is here:
https://wiki.freepbx.org/display/FOP/2023-08-28+SECURITY%3A+Potential+Rest+Phone+Apps+Authentication+issue
There are no known cases of this CVE being exploited in the wild.
2 Likes
Why is this CVE, after 3 weeks, still not published the CVE database? Why did none of us get a notice about serious RCE issues and holes. Silently updating the wiki documents and pushing out a quite update for something like this is just not acceptable.
This also means there should be at least a mass notification that tells/warns people still on FreePBX 14 (perhaps even 13) that there is a major 5 year old exploit that exposes them to major risks and they need to update.
It makes me wonder about that ARI exploit that no one has yet to fully explain or show how these systems where compromised. I’m not sure this presentation covers everything that was found based on some of the comments made during it. Just pointing out the most severe cases.
But I’m more interested in what Sangoma’s response is to the fact that none of the commercial modules have any sort of integrity checks or validation. This presentation covers that fact that the code was de-obfuscated by existing tools that are out in the wild, modified the code to what they wanted, re-obfuscated the code and never once did FreePBX complain or warn about the integrity of the modified files.
It concerns me that the code that was found to have the most exploits and the least security and validation checks are for commercial modules. Modules that we have to pay for but more importantly, code that can’t be scrutinized by the public and thus seems to have lowered the quality of the actual coding and/or QA.
So what is being done to address the serious issues with the commercial module code? I don’t just mean the actual coding but the entire process.
6 Likes
FYI - we had 7-8 FreePBX servers hosted on Vultr compromised through PHP exploits in late August/early September. This is how I first learned of this attack vector. So now you have some known cases - and I’m happy to share any info you need if you want to dig deeper into how our systems were compromised.
13 Likes
You guys are derailing the discussion about how Sangoma is handling security in FreePBX. This thread has value in that discussion. Please take your sniping at each other into DMs as that is an option.
2 Likes
Fair enough but only one of us gets flagged? Very nice.
@lgaetz just posted a detailed blog here FreePBX Security Issue SEC-2023-001 | FreePBX - Let Freedom Ring outlining things.
2 Likes
You do realize that all but one of the flaws covered in this video are commercial modules. There was only one OSS module that had a flaw. If the logic is the paid products, like commercial modules that also run in PBXAct, have priority then that’s a skewed priority.
I was referring to their other products and services other than FreePBX rather than the paid modules. Their focus is somewhere other than FreePBX is the point.
1 Like
Crosstalk posted a video in the last day or so on this. https://youtu.be/xGtJNwWoyHo?si=e0s0dQeaEbzZFhHu
2 Likes
Yes and no?
Security Reporting - FreePBX OpenSource Project - Documentation
Worth noting that both those pages were created 5-7 years ago and last updated well before the page in that way back link was created or deleted.
So I have a question about what was said in that video. Mainly, how did CIP release a patch for CrossTalk of a commercial module(s)?
We did not patch a commercial module. We assisted him in blocking the call to ajax.php but did not patch or touch a Sangoma commercial module to do so.
3 Likes
Ahh so when he said you patched the port, you just put in some firewall rules? an .htaccess rule?
Tom. Your not going to get a step by step here from me. We assisted a paying customer to patch their system from letting the bad guys get in without modify a commercial module in FreePBX. It would be wrong of me and violate contracts with customers and privacy policies to get into exactly what was done. At this point it does not matter as Sangoma has patched the flaw that they were using to get in.
1 Like