Preventing Vulnerabilities in the OJS 3.3.0-20

I have experienced many hacks in my OJS web site. Attackers removed index.php or set index.html instead or redirected to any other web site. Some helper files used for attack were put inside plugin libraries named “gabut”. I explored those by finding executable file list.

My uploaded files directory is outside of root directory that contains config.inc.php. I did not nothing about directory permissions and just downloaded from github and put to the host.
Even I’m using OJS 3.3.0-20 which is long term support, should I pay attention also the plugins that come with installation files? Are they up to date already? I doubted that insecure plugins are causing. Should i give up 3.3 and update to 3.4?

I use OJS 3.3.0-20

Here is the files found infected by antivirus:
image

Thanks in advance.

Hi @srht,

I can’t speak to your specific installation, but if you haven’t already done so, I would highly encourage you to review our recommendations for securing your installation: https://docs.pkp.sfu.ca/admin-guide/en/securing-your-system

As for plugins. It is recommended to use plugins that are only compatible for your particular version. And, also, only install from the plugin gallery.
A tool to help with that can be found here: PKP Plugins List

I can’t quite tell with that specific plugin, but, given what’s happened, uninstalling it would probably be a good idea.

-Roger
PKP Team

1 Like

Hi @srht,

Earlier releases of OJS 3.3.0-x were vulnerable to some stored XSS attacks, and we’ve heard reports that these have been used to escalate privileges via stored Javascript that gets presented to the manager or site admin. We’re not aware of any of these vulnerabilities in OJS 3.3.0-20 – but here are a few things to check if you did suffer a hack on a previous release.

Some of this would apply to any PHP application, and you might find other helpful info on e.g. StackOverflow.

  • If you find a backdoor, before you remove it, see if it can give any hints about the way it was installed. For example, check the date/time it was created; see if anything in your access log corresponds to the same moment. This may tell you when the malicious code was installed, and using what URL, and from what IP address.
  • When cleaning up a hack, make sure you’re not just re-installing a backdoor that the hacker already installed. This means using a tool like diff to search your installation for added or modified files. (It looks like you found a backdoor plugin – this should definitely be removed!)
  • Review your privileged users to make sure that there are no extras:
    1. List all “site administrator” user groups. There should only be one result for this query.
      select * from user_groups where role_id=1;
      
    2. Check all enrolled administrators:
      select u.* from users u join user_user_groups uug on (uug.user_id = u.user_id) join user_groups ug on (ug.role_id = 1 and uug.user_group_id = ug.user_group_id);
      
    3. Check all enrolled managers:
      select u.* from users u join user_user_groups uug on (uug.user_id = u.user_id) join user_groups ug on (ug.role_id = 16 and uug.user_group_id = ug.user_group_id);
      

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Just for information, we have noticed accesses from various IPs looking for hacked OJS instances. One of the patterns of these requests is for /plugins/<category>/<plugin-name>/gabut/<something>.

Mainly looking for /cmd.php?c=id

1 Like

Hi Alex, In a few days I’m trying to check you had shared. I’ve found a user added as admin role and removed. But nonetheless there new attacks happened again.

I applied the security checklist as @rcgillis suggested. But I couldn’t understand which plugin is up to date exactly. There is only 3.3.0 version not for 3.3.0-20. Btw I uninstalled some of plugins. But today in a new attack, .htaccess file was deleted and a directory placed in the root folder. Then I checked the public_html directory permission there was read and execute permissions for everyone and I removed the execute today. So there is only owner has full access and read is for everyone. I’m thinking of upgrade to 3.4 version.

Addition: There are pdfJsViewer and htmlArticleGalley plugins which are not in the list and seems very old. Should I remove them?

Just a reminder to consider that the initial invasion may be from outside OJS. For example, I helped an institution where the invasion occurred through Apache.

As there was compromise beyond OJS, we recommended reinstalling from scratch in a new environment, naturally transporting the database and submitted files, but with OJS and additional plugins installed again from trusted sources, as well as the other usual good practices.

Hi @srht,

The latest OJS 3.3.0-x and 3.4.0-x releases are equally secure; I don’t believe there’s something in these that are permitting the attacks to continue. Upgrading to 3.4.0-x now would probably just be a distraction. As @abadan suggested, I would review everything in your server environment to make sure there isn’t a backdoor script left installed or an insecure set of file permissions (particularly on shared servers).

Regards,
Alec Smecher
Public Knowledge Project Team