We’re running a hosted VPS from a FreePBX Provider, as I was typing this they just got back to me and apparently it is a venerability with FreePBX and PhoneApps, so what is Sangoma current path for securing and fixing this? Is there an ongoing forum already that people are discussing this in?
What tends to be the cause for exploitation?
Thanks! We’ve discovered that the server is being inundated with SED commands which is running 30+ processes
Hi Dicko thanks for getting back to me, so I’ve already followed the cleanup process sent along by the provider. Based on the documentation it was indeed the exploit had all the same users etc… and files. Upon further research It seems that the solution is to do the cleanup and make sure restapps is updated.
I suppose my question then becomes is how was it exploited? Has Sangoma determined what the path in specifically is. IE does just having even the user panel exposed to the public web allow exploration?
Bear in mind that whatever your ‘family jewels’ were they are now likely compromised, these guys now know where your PBX was and if it comes up in the same place, then ‘caveat’, they have long memories and big brains . . .
So was just thinking, does anyone know / seen any inclination of what exactly this exploit was used for? What I’m wondering is for example call recordings or other sensitive information that may have been on boxes or does it seem it was simply an exploit that they used to run say botnets from etc…
Does anyone who had been exploited have any ideas of what the purpose of the exploit was in the end? I take it there’s really no audit trail to determine what would of been accessed IE call recording wise.
Although I have not so been exploited, I would surmise that the intent is to
A) Disrupt your system thus causing mayhem and panic.
B) Steal credentials that might allow calls to be made that you are not aware of
C) Distribute to others that could later exploit such data to your disadvantage, especially while your system is ‘down and out’
I suppose the good thing is at least the carrier is IP dependent on call authentication and not credential based. Then all the phone extensions were generated passwords that were unique thus easily changeable.
As to this specific system it’ll be completely decommissioned and will be relocated to a new infrastructure entirely so re-exploitation based on it being a known system now shouldn’t be too big.
Thanks for the input with any luck the others exploited too weren’t too harshly effected.