Does removing "Register" from top ribbon increase security?

How we use it.
    Persons registering select their roles as reader, reviewer, author, or any combination thereof.
        The reader role does not have the option of posting on the site.  Readers are notified when a new issue is published.
        The reviewer role does not have the option of posting on the site, except as follows:
            Reviewers are invited to review an article; they may accept or decline the invitation. 
            If the reviewer accepts the invitation, he is provided access to the article, and also to a review form to complete and upload-he may also upload additional comments..  The process is built into the software- no outside email
        Authors post their articles according to software rules
            The article is initially in the unassigned category.
                I vet the article to remove identifying data and for evidence of plagiarism
                I assign the article to the theme editors
                The theme editors invite the reviewers
NB  Letters of invitation, assignment, acceptance, decline are all form letters contained with the OJS software; the review forms were created by us.  None of the user roles within the software require or permit outside contact.

Best,

My college hosts two OJS journals (2 separate installations). I have a captcha installed on mine.

A malicious message was posted on the other one, which resulted in IT removing the “Register” link from the top ribbon on both journals, making it impossible for viewers to register on my journal as authors, reviewers, readers.

Is the access of users as reader, reviewer, author strictly contained within those “roles,” or does “registration” open some type of “back door?”

Mel

Access is dependent on the “role” of the user.

Readers and Reviewers are able to edit their own profile, and potentially to post comment on articles (if enabled). Since the profile is exposed in the commenting interface, it is possible for a “malicious” message to be nothing more than inappropriate links or images in the user’s biography.

Authors and Reviewers are able to upload files to the system. If the site is configured correctly, these files should not be executable by public access to the webserver, so a “malicious” file is limited to a submission file with a user-executable virus payload. If misconfigure to allow public, executable access to the private files_dir, this does create a “backdoor” to the system. Such misconfiguration, if it exists, is a critical issue and should be mitigated immediately.

Hiding the “register” link does little to address either issue. Disabling registration entirely would mitigate new malicious users but not affect existing accounts.

Can you provide a little more information about the “malicious message” that caused the concern?

Thank you.
I don’t have specific information, but will try to get it and get back to you.

What I was told:
The New York State Police informed us (IT or the college) that a message warning users of the School of Business Journal that said the site was hacked (potentially dangerous) had been posted. I became aware when IT informed me that the “register” link on my journal (School of Education) was removed to secure the server.
Thank you,
Mel

You might want to invite your IT support folks to this discussion on the forum. I think additional clarification could be helpful.

You either have an overreaction to a functionally harmless defacing attempt by a user editing their own public bio, or you have a security issue which has not been resolved (at least by the mitigation action described).

Thank you, Clinton,

I have invited them to join.

Mel

Hi Clinton,

WE have arrived at a workable compromise:

Good Afternoon Mel & Tom,

Thank you for your email. See answers below.

· The hacker created an account and uploaded a file to the OJS server.

· Matt Rose, NY State Police Department, Intelligence Analyst, Cyber Analysis Unit reached out to us and told us that our site was compromised.

· We engaged our Cyber Security Group and also had a conference call with Matt Rose from NY State Police Department. They recommended that we immediately disabled registrations to both sites. There recommendations were as follows:

o Remove inactive and suspicious accounts that are registered on the website.

o Prevent the creation of accounts without approval by an administrator.

o Creation of process of which request to create an account is reviewed and approved by an administrator.

Change made to the 2 Sites

After researching, Googling, spending time on forums, we have made the following changes:

  1.   Re-enabled “Register” link on both OJS instances.
    
  2.   Users can only register as a “Reader”
    
  3.   To change a registered user’s access to author, you can simply login and change them from “Reader” to “Author”. This will allow the user to upload files
    
  4.   Please only change a user to “Author” once you have verified their identity and are sure that the user is a legitimate user 
    

Doing the above will allow new users to registers, at the same time keeping the sites secure (as Authors will only be granted permission by Mel and Tom). This should also satisfy the recommendation by the Cyber Security Team.

I would just like to reiterate that I see three real possibilities here:

  1. The file uploaded was an image linked in the user’s profile. This hardly qualifies as a security event, but it also is not mitigated by the above steps.
  2. The file uploaded was a submission and the system is incorrectly configured to allow public access to uploaded submission files. The above steps do not fully resolve the issue and technical changes are required to secure your environment.
  3. The file was uploaded through some other vector than the above and details of this incident should be reported to PKP for security purposes.
1 Like

Thank you, Clinton,

I am forwarding your note to IT.

Mel

Clinton,

As part of the remediation, we also moved the files_dir outside of the webapp folder. Besides taking this step, is there anything else that can be done to further secure these kinds of attacks?

Thank you,

Angelo Balbuena

No, moving the files_dir outside of the web accessible folder, presuming you also changed the config.inc.php files_dir setting, is the correct and complete solution.

Edit: this also presumes you have migrated to a clean server installation, or verified that no additional attack vector was installed in the initial attack.

How would we go about migrating to a clean server install and making sure we transfer over any existing journals without transferring any malicious files?

I would:

  • Install the same version of OJS on a new server
  • Copy the files_dir and public files to a location for virus/malware scanning; if clean, copy these to the new server.
  • Copy desired settings in config.inc.php from the old server to the new server.
  • Backup the database on the old server and restore it to the new server. The database contents should be sanity checked as well.
1 Like