of note, a friend who operates a pure honeypot, has informed me he saw an exponential increase in attempts on /admin/config.php passing user/passwords in the POST, with python watermarks (his words) starting on August 13, he said a big caveat is it could have been anything that uses /admin/config.php that they were trying against, but he also said he doesnt believe in coincidences and if it was him, he’d be using a backup from months ago, but making sure all passwords were still changed anyway.
Where is that modular.php file saved? Or is it just a temp file that is deleted afterwards?
Hello, do you plan to share more technical details regarding this issue and its resolution? Since it’a a 10.0, the community might be interested in understanding its origin and the root cause. Curiously, it was discovered in a “commercial module,” where the source code isn’t accessible. Additionally, versions of the framework prior to 17.0.19.31 have exhibited unusual errors related to email notifications.
I also believe that the release note addressing this issue should be revised to be clearer, rather than stating: “17.0.3 Adding validation for the AJAX request parameters.”
1 Like
I’m w orking on a tool, ran out of time last night. This will allow bulk auditing via have I been owned and allow mass updates of password. In the mean time someone could probably use bulkhandler and a script to do some of it
Hi everyone,
From what I’ve read in this post, the vulnerability affects the commercial versions of the Endpoint Manager module. Are PBXs without the licensed version of this module also affected by this vulnerability?
By default, yes. Go to Admin → Module Admin, look at the Settings section. If EndPoint Manager is present and you haven’t updated it, you’re vulnerable.
Even though I would also like to know more about it, probably not a good idea for them to publish all the details.
I have another bonus question: If we never had the Endpoint module installed on our systems… Do we still need to updated other modules like “FreePBX framework”? Or nothing has been improved there regards to security?
Yes, it’s important to always keep all FreePBX modules up to date.
We can never predict which module, service, or port an attack might target, so regular updates are essential for security.
Question is more: Was there another module (than Endpoint manager) updated regards to this issue?
So far the answer is no. The RCE was in code that was found in the endpoint module was it so far.
1 Like
I don’t think understood your question wrongly.. Maybe you have to ask different way?
So, I said. My personal recommend keeping all modules up to date as a best practice for overall system security. Thats all..
1 Like
that sounds like the services/REST API calls may not have JWT authentication implemented.
I haven’t received any emails from this email address in over a year. The last email I received was Aug 1st 2024 about VI’s Expert Compliance.
So @mwhite seems like your notifications system isn’t doing something right.
Update on the endpoint hack:
I had a FreePBX 17 server up for test, which I left open and found it had been compromised.
I enabled some debug logging to see the hack at work and captured a few instances of the hackers entering the system.
(I can confirm from what I saw that the entry point is only via endpoint manager.)
At first the attackers were only testing entry to the system but as of this morning I found the test server’s root password had been changed and my SSH key no longer worked. So, with it inaccessible, the test server is now destroyed.
Be aware that the attack leaves admin users in the database, so even if you patch FreePBX, if you were compromised and don’t clean up (that is to say, rebuild from scratch), the attacker could still get in via the user they left behind.
MariaDB [asterisk]> select * from ampusers;
+-------------+-------+-----------+------------------------------------------+---------------+----------------+----------+----------+
| username | email | extension | password_sha1 | extension_low | extension_high | deptname | sections |
+-------------+-------+-----------+------------------------------------------+---------------+----------------+----------+----------+
| ampuser | | | e30cfb325cba0aeaf7d62e8e9dcd3875ef0d57e4 | | | | ;cli |
| freepbx_svc | | | e30cfb325cba0aeaf7d62e8e9dcd3875ef0d57e4 | | | | ;cli |
+-------------+-------+-----------+------------------------------------------+---------------+----------------+----------+----------+
Note also that if you back up admin users and restore them to a new machine you may restore an “added” user. Beware.
Another reason to get rid of the legacy ampuser stuff
1 Like
Thanks @billsimon for your help on the reporting and analysis as well as @matthewljensen – due credit given to you both in the GitHub issue GHSA-m42g-xg4c-5f3h for CVE-2025-57819.
Curious if that was your add or the attacker(s) ? To date, only ampuser was noted in the ampusers table as an IoC.
Wasn’t me. Notice that the password and permission grants (cli) are the same.
Thanks for sharing this. In this case, was clean.sh or any of the originally mentioned artifacts still left on the system? Now that there’s a patch I’m wondering if attackers are doing a better job of cleaning up artifacts. Are there any endpoint-related requests in access.log?