K.php - a RestApps malicious script

Yes look at all the base64 stuff (it does a lot more than you will see on ‘first blush’ and in a lot more places you are not covering . . . :wink: )

A quick script that is untested but should generally work
This changes all (pj)sip secrets. You will want to apply config after and regenerate any provisioning files. This does not give any form of feedback so to get the new secrets you will have to get them from the database or by going to each extension.

This does NOT touch trunks. You want to regenerate credentials with your sip provider
All devices will 401 after running this and reloading if they try to re-register with the old credentials.
THIS MAY TRIGGER FAIL2BAN!

Should go without saying but:

  • Use on a system that has been cleaned of the hacked code
  • This comes without any form of support or warranty
  • Aliens might be real
1 Like

Good start, thanks.

but note bene

  • Use on a system that has been cleaned of the hacked code

(fully . . . or it will come back)

I would ensure that your /tmp filesystem is truly ephemeral and that you restart the system for good measure. . .

It is such a mess a reinstall is in order.

I just installed a clean system and /etc/rc.d/rc.local has the line

touch /var/lock/subsys/local

Something else. Seems like all my systems that were infected have settings > asterisk sip settings > general sip setting: Allow SIP Guests = On.

Correct me if I’m wrong but I’m pretty sure this is off by default and should be.

It is enabled by default until recently (v16). https://issues.freepbx.org/browse/FREEPBX-22914

1 Like

Quite complex to find what to do at the end?
I also installed Webmin temporarily to check the Crontabs for those unfamiliar with cron in terminals.
I was happy but some days later it came back, I have to admit I’m not 100% sure, but I’ve tried now all things found on this page. It’s strange that there is no automatic update that would try to clean things, especially with a fix IP address.

in the cli

fwconsole validate --clean

then:

fwconsole ma refreshignatures

this won’t clean everything and you probably still need to build a new clean system from scratch to be sure. Until you can I’d run the validate script once a day…

You have to understand the attack vector is the same but the payload can be anything. I have watched this evolve and have seen new things added to the payloads. The attack and payload could change every attack if it wanted to. The purpose of this post is more centered around what to look for. It’ll give you an ideal of different things that are being changed so you know where to look. Your system may have completely unique information on it. The only way to truly fix a compromised system is to nuke it.

I started writing a script based on the original payload and the next day new information appeared where somebody had a different payload. Nobody wants to make a full-time job out of keeping up with these payloads. Simply nuke your server and create a new one

2 Likes

I understand. The thing is I tried 7 times to backup a server and restore them, but it just never worked.
I don’t really trust these scripts, sadly, so it’s a huge huge huge thing, and pricey, to make a new server.
I miss malware byte there :slight_smile:

Reinstall FreePBX15 over the existing server. Bring it fully up to date/secure it.

As long as you have a backup file that’s at least FreePBX13,14, or 15 then you should be able to load that in using the restore tool.

What issues are you experiencing with restoring a server? The only expense should be down time and inconvenience.

When I had to migrate from I think 14 to 15, the update script failed.
Last time I also migrated the server, I made a backup and restored, failed.
Always had to redo everything manually. So I’m not a fan of this.

Are you transferring the activation ID first before attempting the restore? And is the system you’re restoring to up to date on its modules/OS?

It may have been done differently, now that I’m hosting the machine, the only way for me would be to backup, deactivate, reinstall and activate, update and restore… But this might have a longer impact especially that the support have to reset my license all the time :slight_smile:
So, again, I’m not a huge fan of this. If no choice, I’ll do it and try. But for now, all helps given there seems to help.

I do know if your MAC address changes, you lose your activation. Some VM environments also assign dynamic MACs, so a simple reboot jettisons the activation. Might be able to get around the reset if you can keep the original values.

2 posts were split to a new topic: Restoring commercial module data to unactivated system

Sidebar…

I’m working on a script to scan and clean-up using factors that seem to be entirely consistent across all cases of this k.php mess we’ve seen thus far, but I’m running into an issue calling validate --clean reliably due to this timeout.

(Yes, I will share the script when ready and intend on keeping it up-to-date as needed. It won’t be restricted to AWS FreePBX, allowing anyone to use it to [mostly] safely scan and/or clean a system…at least well enough to afford you a chance to migrate to a clean install/instance/server. So, feel free to keep this thread updated with new information that I’ll be happy to reference alongside my own research.)

1 Like

Alright. Here’s the script:

https://files.thewebmachine.net/awsfpbx/cleanup-kphp.sh

If an AWS FreePBX customer, simply run SmartUpgrade cleanup-kphp
Everyone else can go about it the typical way:

wget https://files.thewebmachine.net/awsfpbx/cleanup-kphp.sh
chmod +x cleanup-kphp.sh
sudo ./cleanup-kphp.sh

It starts off with a scan (that doesn’t make any changes) and reports if it found any references to k.php, wget entries in rc.local/.bash* files, crontab, the known bad files created by the mal-scripts, the maliciously created users, etc.

After the scan and results, you can proceed with clean-up, which will:

  • scrub all those affected files
  • perform ‘validate --clean’ and ‘ma refreshsignatures’ via fwconsole
  • fully reinstall the latest versions of framework, core, restapps modules to ensure they are clean
  • remove the malicious user accounts
  • rotate the Asterisk Manager password connecting Asterisk and the FreePBX GUI
  • fully scrub temp files from the system
  • force a reboot to complete clean up of active memory

The script is fairly straight forward. A mandatory reboot happens at the very end to kill off things that might be running in memory that could reinfect…and to finish removing the maliciously added user accounts.

IMPORTANT NOTES:

  • All data used to construct the script was taken from this forum thread and our own notes from cleaning up multiple infected systems over the last few weeks. If anyone find anything new, reply in this thread, as we’ll do our best to update the script if we find new bits or better ways to detect it
  • This should clean up enough to kill off the background/cron reinstalls and anything running as those added users. While you could, in theory, carry on with this cleaned system (after rotating passwords and such), we STRONGLY SUGGEST you only use this to clean up your system enough to extract your config VIA BULK HANDLER - as we can’t be sure Backup/Restore won’t carry over bad remnants - and import that config into a new server/instance/install
    • Pro Tip: When using Bulk Handler to move your config, you can change all the Extension secrets at one time by changing the ‘secret’ field to “REGEN” before importing (use CTRL+d to fill down a column in Excel/Calc)
  • We do NOT rotate any other credentials beyond the main Asterisk Manager password to protect AMI access in case that password was skimmed. Your GUI passwords, SSH keys, Extension and Trunk secrets, etc remain unchanged and you should definitely change these (especially Trunks) ASAP after cleanup!
  • While this script should be safe for most systems, there are always risks, especially when running the ‘validate --clean’ process against a heavily modified/advanced setup. Be sure you have proper backups (AWS users should create a Machine Image backup) before you begin the clean phase!!!

UPDATES:

  • 2022-02-18
    • Added --scan-only parameter to quickly check and exit; returns an exit code equal to number of flags found (0 = presumed uninfected) - useful for programmatic/scheduled checks
    • Added new checks for variant that installs Go Version Manager (gvm) to download and maintain malicious code (NOTE: clean phase will completely remove /root/.gvm/!)
    • Added check for vulnerable restapps version (regardless of infection status) and alerts if vulnerable version found
3 Likes

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.