As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

We haven't had any reports of OJS being used as a launching point for attacks. Typically these sorts of attacks are mounted via mechanisms like remote include exploits (see http://en.wikipedia.org/wiki/Remote_File_Inclusion), which we're confident that OJS is not vulnerable to, or upload exploits that OJS shouldn't be vulnerable to either.

The source of an intrusion is often very difficult to track down, but I'd suggest finding out the exact moment the hacked file was written; if you look through the web server access log for a request made at the same moment, there will often be an entry there for an intrusion attempt made on a vulnerable script.

If you set your file permissions wide open (e.g. 777), someone else on a multi-user system could have used your file area to launch attacks without needing to find a vulnerability on your website. You should never use 777 permissions on a production server; many alternatives are available but will depend on your server configuration.

If you are able to determine the source of the attack, please follow up here.

Having just undertaken and completed a reasonably comprehensive look at various e-journal publishing packages, I noted one feature present in Aries' Editorial Manager is virus scanning of submissions.

Is anyone working on this for OJS? What would be your sense of the complexity of implementation? I haven't looked at the source at all with this in mind, but suspect it wouldn't be too bad; just look for a hook after the upload has been processed and write a plugin registered against that hook.

Here he talks about cases where people can leave javascript on other peoples sites via comment mechanisms etc. The hackers leave javascript of small pictures (1x1 transparent pixels). When a person views the site, their browser finds the javascript and retrieves the image from the hackers site.

In our case, someone must have been able to log in as a journal manager, and re-edit the home page, displaying a small black image. Our banner is also black but it was displayed below so he must have mucked up.

Another thing I must note, is that we had very insecure passwords at that stage, and there were a couple of occasions where FTP passwords and OJS passwords were passed around over email. We were also set up with MD5 password encryption, and not using SSL for logins. We have changed all this now.

So to conclude at this stage, I think, due to our lack of security measures (ie SSL, SHA1, Emailing). Someone sniffed out our passwords and simply logged in.

-------------------------------------------------------------------------------------
Just to summarise the facts, maybe some can dignose other possibliities.:

1. 1x1 pixel showing up on our home page. We dismissed it as 'something funny'.

2. The website downloads trojan viruses to people viewing the site. Especially to those using internet explorer.

3. File permission settings in cache were set to wide open. (777). The cache/t_compile directory contained the virus.

Thanks for the additional information, and good luck with the cleanup. We vet all information from users for all roles below Journal Manager -- but the Journal Manager and Admin have carte blanche to post whatever Javascript or HTML they want in textbox fields. This is the case because there are so many legitimate uses for Javascript and HTML in these cases -- restricting that kind of content would cripple the system.

If you haven't updated your virus definitions and browsers on your client systems, I'd do so -- a common way for passwords to be sniffed is through client-side keylogging programs, where security is typically far lower than on servers.

I had best mention a hack also. Last night (1-20-09) our index file (permissions rw-r-r) was altered: a JS/Psyme trojan was added. I replaced the file and have changed the J-Manager access info. We intend to replace system files with a back-up copy later. I'd love to know just how they got in. The pw was strong.

If the hack was accomplished via PHP, look at the modified date of the compromised script. Then take the date and time and look for a corresponding request in your web server access log. If you find something that matches and looks questionable, let me know and I'll investigate further.

One follow-up note -- in my experience, break-ins that result in standard trojans being installed are typically carried out by random scans for common applications with known issues (i.e. old versions of Drupal or phpMyAdmin). If a scan finds a vulnerability, they'll use it to search your web space for files to infect (typically anything called index.php) and will install the trojan there, potentially in multiple places. In other words, In addition to the above suggestion, I'd do a survey of applications installed on your web space and see if one of them has a known flaw.

This may also depend on the type of API your server uses to communicate with PHP; if you're using mod_php, anything that belongs to "www-data" or "nobody" or "apache" (specifics will depend on your server configuration) is vulnerable to modification by anyone else who has the ability to write PHP scripts on the server, or anyone who can compromise one of those scripts -- in the case of a shared server, this is potentially a lot of people. For that reason, we strongly recommend using a host that supports PHP via CGI or FastCGI in a SetUID environment.

The culprit was revealed in the log files and pointed to a script (old version of phpBB) I had all be forgotten about - my bad! We deleted it, restored the rest of the site from a backup and, jic, I added a ban list via htaccess adapted from: http://www.ewebsite.biz/modules.php?nam ... ccess.html.

Great, glad you found it -- and that it wasn't OJS! In any case, these random scans generally guess for applications installed in their usual places (e.g. /phpbb or /drupal); often you can avoid many of these scans by simply changing the directory that you install the application in.