Until you have clarity I recommend keeping your pbx shut down and deleting your forum account. You never know!
(Don’t mind me; I’m just being odious!)
3 Likes
This isn’t a real world solution - companies can’t just ‘shut down’ their PBX systems.
To help mitigate this issue - here is what I would recommend you do on your own PBX systems, or for your customer PBX systems ASAP:
-
Change your Sangoma portal account passwords - there has been nothing to indicate that customer or portal login information has been compromised, but it’s generally a best practice to change these passwords on a regular basis anyway, so now is a good time. And, Sangoma recommended to do this in their public statement.
-
Remove any Sangoma keys from the .ssh/authorized_keys file - if your server has ever connected into Sangoma support, their keys will likely be on your server. Simply find any of the keys with ‘Sangoma’ in the name and delete those lines (be careful not to delete any keys that you actually need for your own access). For our own customers, we have a central VPN-secured management system that allowed us to run a command against all of our customer servers that found those Sangoma keys and removed them. If Sangoma ever needs to connect again, they’ll just have to re-add the keys the normal way.
This can also be achieved in the FreePBX GUI by going to Admin → Sys Admin → Support and clicking ‘remove’ on the SSH Keys Package (if it’s showing a key installed).
-
Ensure that any Sangoma support VPN services are stopped and unconfigured - this can be done by going to Admin → Sys Admin → Support VPN. Disable anything you find here - definitely do not leave this VPN connected.
-
Verify and audit all firewall settings (corporate firewall and FreePBX firewall). If you have a corporate firewall in front of your FreePBX, ensure that only the ports you need open through to the FreePBX server are open, and ideally, lock those ports down to only the source WAN IP addresses that need to connect to the FreePBX from the outside world.
Similarly, go through your FreePBX firewall settings - make sure the firewall is on and properly configured so that you are only whitelisting the IP addresses that actually need to connect into the PBX (such as a remote office or SIP trunk provider). Most of the authorized networks/hosts in your ‘Networks’ tab should be in the ‘Local’ zone, and very few should be ‘Trusted.’ ‘Trusted’ zone should be only for IP addresses and LAN segments that need to administer the FreePBX (actually administer it, not just use it for phone calls and what not) - everyone else should be in the ‘Local’ zone.
I typically recommend keeping the Responsive Firewall disabled unless you actually need it (for instance, if you have a significant number of home users on dynamic WAN IP addresses, or employees who regularly use softphones from their smartphones to connect into the PBX). We find that the majority of our customers do not need to have the Responsive Firewall enabled.
These steps will go a long way to mitigate any potential breach. We currently DON’T KNOW the full extent of the information that was lost/leaked/whatever, so it’s better to err on the side of caution. But simply turning off your PBX is not realistic.
If you know of additional security steps that folks should take that I didn’t think of - please respond to this thread - it will be good community information. ESPECIALLY if Sangoma has anything to add here - as I’m typing this message, I’m sitting here thinking that this is the type of information we should be hearing from Sangoma…not from some random FreePBX user in a community forum post.
-Chris
5 Likes
The CLI equivalent is running yum -y remove ssh_keys if anyone wants to script this.
That’s recommended anyway unless you have an active support ticket, but bears repeating. The CLI equivalent in 15 is to run the script /var/www/html/admin/modules/sysadmin/hooks/support-vpn-stop
4 Likes
No need to troll, it’s not helpful. Actually what we’ve done is completely isolated the phone VLAN’s from the corporate networks completely. We then brought the PBX’s back up. We’ve shutdown any traffic inter VLAN, and will slowly firewall / SIEM traffic in between. I stress that I’m concerned about code injected backdoors onto the network, not direct incursion into the PBX itself.
This is the way people should do it anyway. I never liked the ideal of the PBX and phone network running with the main network. The idea that someone can walk in to your lobby and plug in a travel router and own your network from their car is insane.
Lawsuits…
Or just Suits.
2 Likes
Alright so I find this quite interesting. While everyone is busy coming down on Sangoma for not saying enough, everyone else seems to be saying more than they need to.
What is even more funny is the panty bunching about the Master Key. Funny that in the start of 2020 no one seemed to care that former employees of Sangoma had the Master Key. In fact they were very upset when Sangoma tried to protect their Master Key and was going to cut ClearlyIP out of the system for using it. So let’s keep that in mind, the Master Key was already IN THE WILD in early 2020. No one raised a stink about it then. I mean I could FUD the hell out of this. What if one of those people got hit with ransomware themselves or compromised in another way. How many of those former employees had a copy of it? How are they protecting their own stuff?
I can tell you that no one really cared earlier this year about that. They were more concerned with labelling Sangoma as bad, bad people for saying they were going to remove ClearlyIP modules.
As for the CrossTalk video. Last half of that video, spot on. Informative, helpful and providing advice and tips for those concerned about the security of their PBX. The first half, not so much. It was a bunch of assertions with basically “I could be wrong. Please Sangoma tell me I’m wrong.” and that doesn’t help. The end result will be people pointing to the video with the thought process “Well he told Sangoma to prove him wrong and they’re silent. He must be right”.
So again, people need to stop saying so much while knowing so little. You’re not helping.
Parting thought, it didn’t matter if the ransomware only got a personal directory with Grandma Ethel’s best baking recipes. The company got breached, they have to disclose that. The disclosure itself, regardless if there was no real data stolen, is still damaging to the victim of the ransomware.
6 Likes
No. It was not “in the wild”, I have it. I have not distributed it to anyone else. It is still secure, and will remain so, unless SOMEONE ELSE does something dumb. Also the master key was never on any infrastructure that could have been attacked from a windows/cryptolock style attack - in fact, I only kept it on an encrypted VM that was powered off most of the time. I’m not sure what Sangoma have done since then.
Yeah, and there’s a LOT of files called things like ‘Complete Employee List’. When this originally happened (I heard rumours about this a few months ago, but just dismissed it as exactly that - rumours), I assumed that if it was true they would have released a statement saying it, as they are legally obliged to do.
Anyway, I’m just waiting for someone to download the archives and put them somewhere accessible. At the moment it’s all just hypothesis.
Let’s crack on securing our servers and systems, and then notify end users that’s what we’ve done, if appropriate. Thanks for the help and advice @Crosstalk, you brought this to our attention and we are grateful although, frankly, most of this should be done as standard anyway. Best wishes
to Sangoma dealing with this sh*t over Xmas.
But is there anything in there your not already doing?
“I want to put out this video to sort of get ahead of any speculation…” Followed by 10 minutes of speculation.
2 Likes
Just because you are paranoiac, that doesn’t mean folks are not out to get you.
BUT so far after 23G of releases, the files available for download, although embarrassing for Sangoma, seem to be limited to financial data since 2008, as yet I see no hint of Technical data compromise.
(take that for what it’s worth, but perhaps, remembering the words of Douglas Adams, “Don’t panic” , perhaps until more than 42% of the data dump is released at least 
)
2 Likes
By in the wild I mean outside of control of Sangoma. I understand you can sit there and say how secure it really is, just like Sangoma could say they were but hey, they got breached. So if it was you that ended up getting breached, you don’t have to disclose to us you did but if they got that master key then Sangoma is also now at risk. See my point on that?
Well that would require me to have FreePBX systems that I directly admin. Don’t really have those anymore.
Yes because it’s not like people haven’t ignored those parts and just bit into the juicy parts and only took those away as talking points. It also goes to my point of, we don’t know things so just spewing speculation should just be not done. It can actually make it worse and do more damage.
Were I to conjecture, the windows machine of an officer of a company was compromised, gaining the ‘dumbass’ attacker access to a vpn used that exposed ‘lots of shit’ , none of that shit sofar should impact any day to day ops of your PBI.
They might know how much you paid on payPal though.
1 Like
And here we go. Yes, we are well aware of how ransomware works but flat out saying they ignored it like it would just go away is just pure speculation spew (again). Many companies do not pay the ransomware while other do pay it. Those companies have their reasons for doing either of those. In cases like Sangoma, a large corp, there could be a legal team saying “Don’t pay”.
Ya sure about that? Because spending 15 minutes reviewing that law show this:
An entity must take all reasonable steps to complete the assessment within 30 calendar days after the day the entity became aware of the grounds (or information) that caused it to suspect an eligible data breach (s 26WH(2)).
Timing of notification
Entities must notify individuals as soon as practicable after completing the statement prepared for notifying the Commissioner (s 26WL(3)).
Oh and apparently there are three ways to do notifications.
- All Users - Blanket statement.
- Impacted Users - If you know exactly who was impacted, just notify them not all users.
- Don’t have current contact information? You just need to public post on your website the details of the breach.
So yeah, in Australia they would have 30 days to put the report together for the regulators after they found the breach. THEN they would do notifications.
Alabama and California where they have offices both do too. ¯_(ツ)_/¯ I’m sure the lawyers told them it’s cool.
Yeah, that is a good point. All 50 states have their own laws about how to handle, report and do notifications of data breaches. Wonder what other impact there is since there are also offices in Canada and the UK.