Sangoma was recently made aware of a significant security vulnerability affecting the administrator web interface for current versions of FreePBX and PBXact. Sangoma has published updated FreePBX and PBXact modules (for the “framework” module) to our mirror servers, and they should be available to you now. Many modern FreePBX systems are set to automatically apply security updates, but we STRONGLY encourage you to check all of your FreePBX systems to make sure that they have updated to the new version. To do this, please go to Admin -> Module Admin and make sure the “FreePBX Framework” is greater than or equal to one of the following versions:
For FreePBX/PBXact 13: v220.127.116.11
For FreePBX/PBXact 14: v18.104.22.168
For FreePBX/PBXact 15: v22.214.171.124
You may also check the version of the modules from the Linux command-line on your FreePBX/PBXact system by running “fwconsole ma list” and looking at the version of the “framework” module.
While keeping your system up to date is critical in preventing security issues, we also encourage all FreePBX and PBXAct users to follow strong security practices, such as limiting exposure of your FreePBX or PBXact Admin GUI whenever possible.
We would like to publicly thank those who reported this issue to us in a responsible manner. This responsible disclosure allowed us to prepare updates and make them available before public disclosure of the vulnerability, so that FreePBX users can secure their systems.
Due to the concerning nature of the exploit, we’re trying to keep the details of the attack vector from getting leaked. It’s safe to say that if you have a system that has the admin portal exposed to the open internet, you should take precautions to verify that nothing is amiss, such as auditing admin and user accounts and verifying that they are in order (no suspicious new accounts, etc). Also, it never hurts to reset your upstream SIP provider credentials/password in case you’re using username/password auth with them.
Finally, it might not hurt to clear the php session tokens and force a login from all users again (depending on how deeply you’d like to go through this process).
You can do that at an ssh console with the following command: rm -f /var/lib/php/session/*
Hope that helps a bit, and sorry to have to break the bad news.
I wasn’t after specifics, just an idea of what the exploit relates to, which you have explained well enough.
Based on the timing, It sounds like we have fell victim to this exploit. The extension that was compromised had a random password on it that I would not have used. This was a red flag for me. Luckily we caught the exploit before they spent too much on calls to Morroco.
We had already blocked web access to the admin portal. As all extension secrets are visible from the admin UI, I am guessing it’s probably best that we go and reset all the passwords.
I will also have a look for any new users in the Admin Panel.
If we did not have the Admin Portal (Port 443 on the FreePBX servers in our case) accessible to the open web, we probably didn’t have anything malicious happen… unless it came from an inside device with access to port 443 on the FreePBX Servers.
Can you confirm that is a correct understanding?
For us, we only have the Standard SIP ports and the Media Ports Open to the web. The SIP ports are limited to inbound access only from our specific Provider IPs.
That is correct. If you didn’t have the admin portal accessible on the open web, the only attacker that might be of concern is someone operating inside your network, and for most people that means you’re safe
Thank you Sangoma for jumping on this right away. I can also appreciate the desire to also keep the attack methodology under wraps.
I have taken a look at the Linux side of the logging: secure, messages, that sort of thing, but am wondering if an audit trail exists to tell who accessed and who was denied the login screen. Is there a simple log file somewhere that I am missing that would show if anyone was able to access via the fault?