Ok, so Sangoma has had a ransomware attack.
Sangoma, developers of FreePBX, have been hit with ransomware | Hacker News (ycombinator.com)
What now? Is the code safe? Do us PBXact users stop updates? Are the SSL keys safe? I don’t want a backdoor hack a la Solarwinds.
Press release from Dec 24, 2020
Press release from Dec 29, 2020
Press release Jan 12, 2021
Just when you think you’re in the home stretch of this miserable year, 2020 delivers a parting sucker-punch.
There is 8 more days… Buckle up buttercup
tl;dr as a customer/user your probably fine. I haven’t looked at the entire file list but it all revolves around files a CFO has.
That’s just a teaser. Hackers clearly offloaded files, which means they were in the network for awhile. I’m concerned with commercial modules / updates and especially SSH keys.
There’s no value in speculation, only facts.
There’s LOTS of value in speculation. We need to know immediately if we need to shutdown our phone servers, which I have done until we know differently.
Than any level of speculation would suggest that you immediately shutdown your phone servers but there is another synonym for speculation, guessing 
I have shut down my servers, put back the copper lines, and pulled Ethel out of retirement to sit back at the switch board.
(Ernestine, I sometime still use:-
" * Have I reached the party to whom I am speaking?"
)
lgaetz did say there’s no reason for concern about FreePBX, but if you don’t believe him, the one thing that comes to mind would be to remove the support SSH key (if you installed it). Otherwise what vector might there be for intrusion?
BillSimon - well said. We need to be smart, but not over react. We have removed all Sangoma SSH keys and we have removed Sangoma whitelist entries on our firewalls. Apart from that, the only other vector would be a “Solarwinds Orion” type of hack, where a threat actor has infiltrated module updates that gives the threat actor access to our PBXes - but I think that is far less likely, especially based upon the files that have been released, which all look like financial docs.
This really drives the question of security in general at Sangoma and specifically in business operations. Firewall setup, email security, least privilege, zero trust, workstation lockdowns, SIEM - it seems it must not have existed. I hope the tech folks at Sangoma have taken more precaution than the business operations people.
I’m not worried about SSH, we don’t leave that open. I’m worried about the Solarwinds type vector, specifically from closed modules. This was broken publicly, rather than from Sangoma. So they don’t know what they don’t know. There’s every reason to overreact right now.
them physically modifying the modules would trigger the module signature warnings. The process of signing/encoding/releasing commercial modules in to the repository isn’t a passive task. There are multiple steps needed. There are probably 2 or 3 staff members who know how so it is unlikely some random person is going to figure it out on a whim and do it in a way you won’t notice.
But the attackers could replace some tool with a tainted version and wait for new versions of the modules to be released in the normal way.
100% agree with this. Removing Sangoma support keys from all servers that have ever connected with Sangoma Support is a no-brainer, but we need to hear from Sangoma:
Regarding #2, it’s not going to be enough for Sangoma to say ‘We checked - everything is fine.’ We are going to need verification from an independent 3rd party cybersecurity / forensics team to make their findings public. I would like to know if and when this type of investigation is happening.
This is really scary for those of us who have built businesses around FreePBX and Sangoma products. The mishandling of this type of security incident can have years-long implications on both the company and the customer’s trust in the company - please don’t screw it up…take whatever steps are necessary to recover from this completely and with full transparency.
The security playing field is overwhelmingly tilted in favor of the attacker:
Defense has to succeed every time, attacker only has to succeed once.
For the defense, security is an overhead expense that directly subtracts from the bottom line. They will spend the minimum required for what they believe is ‘adequate’ security. The offense will spend what’s needed to get the job done, provided that’s less than the perceived payoff.
For defense personnel, security is a nuisance. Do what seems necessary and get back to the business of selling phones, phone systems and software. For offense personnel, that’s their job. With sufficient skill and motivation, cracking a system can be surprisingly inexpensive.
