Describe the issue or problem
hacker able to install plugin and change content in the server rootkitninja ojs 3.4.0.5
how to trace when the hacker install the plugin and can we trace which account install it?
it install in import export plugin directory
seems alot of ojs installation is affected by this mostly from indonesia.
Hi, I am working with OJS 3.3.0-19, and the service is vulnerable to a rootkit. I don’t know which patch to use. It seems that 3.3.0-20 is also vulnerable (bug on GitHub). There are several posts in the forum, but I don’t understand how to solve this issue or whether I need to wait for the release of 3.3.0-21.
We had to disconnect the server to prevent data loss from affecting the service we have been providing.
OJS 3.3.0-20 can be patched with this patch, which can be applied in lib/pkp.
In order for this issue to be accessed, a malicious user must already have access to a Journal Manager account, which is already a significant breach. We are not aware of any flaw in the current release of OJS (3.3.0-20 at the moment) that would permit Journal Manager access without a malicious user already having a username and password. I would recommend investigating that e.g. in your access logs and user database.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks for your response. I would like to confirm if the correct steps to address the issue are:
Upgrading from OJS 3.3.0-19 to 3.3.0-20
Applying the patch
Removing the compromised user account
Would these steps be enough to secure the system, or is there anything else we should consider?
Additionally, we had to disconnect the server to prevent further data loss and service disruption. Any guidance on how to proceed safely would be greatly appreciated.
If a rootkit was installed, then you won’t be able to trust the contents of your web root. It’s possible that additional PHP code was introduced there.
The parts of OJS that live in the web root are the source code, configuration file, and public directory. The source code will not be carried across with an upgrade to 3.3.0-20, so you’ll be starting clean there. Review the configuration file and contents of the public directory and ensure they are legit (e.g. free of executable code).
The contents of the files_dir (see config.inc.php) should live outside the web root and are not susceptible to remote execution.
See this thread for some additional guidance:
Regards,
Alec Smecher
Public Knowledge Project Team