Preventing Vulnerabilities in the OJS 3.3.0-20

Software Support
3

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

2 Likes