compromised site, some questions

[Ramsesx]

Hi, somebody compromised my site to place crappy ads, some files were changed or newly added. 

I compared the init.php with the latest download. They diff only as following:

$uniqueKey = mb_substr( md5( '2****'

and

'CACHEBUST_KEY'        => mb_substr( md5( 'b****' 

 

So I'm not sure for what those  keys are necessary. But is it save to just replace the old init.php with the new downloaded version?

[DawPi]

Those keys are fine and used by build in cache system. 

[Jim M]

As a general rule of thumb, if someone has gained access to your file system, replacing all the core files with what is from our Client Area is advised and performing a detail inspection of your file system to ensure there aren’t any back doors, etc…

Of course, change your hosting/server/administrator related passwords and keys. Contact should be made to your server administrator or hosting provider as well.

[Ramsesx]

On 6/10/2022 at 2:43 PM, Jim M said:

As a general rule of thumb, if someone has gained access to your file system, replacing all the core files with what is from our Client Area is advised and performing a detail inspection of your file system to ensure there aren’t any back doors, etc…

Of course, change your hosting/server/administrator related passwords and keys. Contact should be made to your server administrator or hosting provider as well.

Yes thanks. I'm still investigating how the intruder did get access to my server, it's the worst attack ever on my site and still ongoing.

[sibomots]

On 6/11/2022 at 6:53 AM, Ramsesx said:

Yes thanks. I'm still investigating how the intruder did get access to my server, it's the worst attack ever on my site and still ongoing.

I didn't see in the OP if the site as self hosted on a system that can provide key authentication or not.

My advice, if it's a unix-like system (Linux, etc..) and self-hosted

1. Don't use plain text password authentication with SSH.  Use Keys.

2. Do you have shell users on your system who can come and go as they please?  If so, then re-organize your user/group permissions such that these 'guest' users cannot modify your site files. A little finesse with user/group permissions for the shell users on the site would be in order. If you don't have users crawling around your system (on your staff), disregard.  See also man pages for `chown`, `chgrp`, `chmod` and `umask`

3. You're right that it's a problem -- how someone got shell access to modify the files means you have more than an IPS access issue to deal with.  They were in the system.  I could not sleep with that situation -- someone not authorized to do so crawling around my system?  I'd nuke it from orbit, and re-image and begin to evaluate what the worst case scenario is --- is/was any thing on the system personal information?

/onsoapbox

If it was me, I'd extract the Database, save off any important data, save what you want to keep, etc..

Flea-bomb the entire machine (flatten it and reimage) reinstall the OS, etc.. and then re-install what has to go back on, re-install IPS, etc.. But this time tighten down the access.  No password authentication to the site.  Got to use keys.  That's a start.

/offsoapbox