OJS site hacked

[stabb]

Hi there

First of all please excuse myself, I am still quite a new to OJS and web site development altogther.

I am helping an employer move an existing academic journal onto an OJS system but we are running into troubles. Any help, advise or direction would be greatly appreciated.

Firstly we had no problems setting up the website and following the very helpful instructions, we are now coming to understand how OJS works and am so far very pleased with what it has to offer.

After about a week of testing, publishing articles and reviewing etc we found our site infected with a Trojan Downloader Laugma.AB virus. It was downloading other viruses to client machines.

I am unsure how this happened, but I suspect it had something to do with the file permission settings that we had to change on installation.



I did this by using the file properties via my ftp client as opposed to the unix commandl; I havent taken the time to learn to do this yet.

My question is: is this the reason we got hacked, and is there some other way we can avoid this?. If not any ideas would be much appreciated.

Thanks alot
James

+++++++++++
We're using
OJS2.1.1
Linux web server.
Php 4.4.6
MySQL 4.1.20
+++++++++++

[asmecher]

Hi James,

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.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/

[rmichael]

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.

I'd likely look at clamav to use as an engine.

[stabb]

I just wanted to follow up on this thread since I think we're getting clues as to what actually happened.

Firstly, I want to point out, that about a week prior to the virus attacks we noticed one or two small pixels on our front page of OJS.

Recently I came across this google.video
http://video.google.com/videoplay?docid ... 0663884360

Jump to 55min.05sec.

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.

4. insecure passwords, SSL disabled, MD5 pw encryption, + we emailed ftp and OJS pwds on occasions.


------------------------------------------------------------------------------------

[asmecher]

Hi stabb,

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.

Regards,
Alec Smecher
Public Knowledge Project Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/

[soj]

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.

soj

[asmecher]

Hi soj,

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.

Regards,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi soj,

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.

Regards,
Alec Smecher
Public Knowledge Project Team

[soj]

Gack. We are not running any other php scripts on our space. But Thanks! I pass the rest of your info along to our host! Will follow up if there is anything more to be said.
soj

[soj]

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.

Hope this helps others too!

Thanks again! soj

[asmecher]

Hi soj,

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.

Regards,
Alec Smecher
Public Knowledge Project Team