Security issue: Hacking via submission in OJS 2.4.8

Thanks, Alec, for checking into that.

Hallo,

My journals website was also hit today,

I followed your instructions above and moved the files directory outside the webroot and configured the Config file to read it.

but the problem still there
here is my weblink for one of the journals in that website the rest are giving the same problem (blank screen)

http://asrongo.org/journals/index.php/AJE/index

Please advice me

Hi @yasser,

Once your server has been accessed by a hacker, it’s good policy not to trust anything on it. As usual, your PHP error log will probably indicate an error message that corresponds to the blank page, but I would suggest either replacing your OJS code with a fresh copy (and reviewing everything that you haven’t replaced), or using a standard tool like diff to compare your installation against the stock version of the same release.

Regards,
Alec Smecher
Public Knowledge Project Team

HI,
thanks… i could return the system back to work, i found that the Hacker could delete some sub-folders plus the Cash folder, i got them back from the backup and it works fine now,
now i have to find out how could he reach that far to delete these folders
is there any help to find out?

Hi @yasser,

Cleaning up after a security incursion is beyond the scope of this forum, but broadly speaking, it’s good policy not to trust content there. I’d suggest using diff to compare your installation against the stock release of OJS 2.4.8 – there’s too much content there to reliably check by hand.

It’s common practice to leave a PHP backdoor installed after this kind of a break-in, so it’s definitely not safe to trust your setup once you’ve got it working again.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @yasser,

Can you please tell which folders and files you upload from backup again. I tried the “cache” folder but problem still continue.

Thanks
Gorkem

Alec, how about a small web based tool that would scan each OJS site for this vulnerability? People could request their site be scanned and you or a website would email them the results. That way the code or vulnerability is not in the wild.

Hi radjr

There are a myriad of technical and legal reasons why that would not be a good idea. Legally doing a vulnerability scan on someone else’s server is fraught with problems, from checking if the requester has authorization and even with any subsequent opinion on whether a site has passed or is OK. The only person doing a scan of your system should be yourself. Also technically such a system could also itself be abused. The only sure way is to read the README on installation before installing and follow its advice. And trying to blacklist extensions leads to a false security.

Mike

A potentially good implementation of this would be similar to the Drupal status report functionality, which checks internally if files paths expected to be private appear to be accessible by HTTP request (at least from itself). This check is, of course, imperfect and could result in a false negative, but would likely catch a number of bad configurations for folks who aren’t reading the documentation and aren’t reading the installation instructions.

Dear Alec,
Just installing the new codes will solve the problem.
What about database, Is database is immune to such attacks?
Can you please tell us what we need to do with our database in such condition.
VJ.

Hi @drvenkatesanj,

I’ve posted on this question on your other thread. (It’s better to just post once – otherwise the forum gets cluttered.)

Regards,
Alec Smecher
Public Knowledge Project Team

We are currently having another similar problem with the cache folder. Hackers are able to create folders and files under this folder because the cache folder is set to writable by ‘others’. It has to be under the httpdocs folder by design as well. Is there are a way to solve this problem without compromising functionality of the system. Thank you!

Hi,

Do you mean that your folder permissions of cache are 777?

Hi @r2d2,

It’s never safe to set the “other” flag to writable, and OJS doesn’t require this. Can you describe your server environment a little?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec and ajnyga,

It is a dedicated server running on Ubuntu 14.04 LTS with the following software:
Plesk 12.5.50
PHP 5.5.9
MySQL 5.5.54

The cache folder is set to chmod 757 (drwxr-xrwx). If the write privilege is removed from the ‘other’, then the system does not work.

PS: The files directory is NOT under the httpdocs folder; it is above it and not web accessible.

Do you mean that you can not give the folder ownership to the web user like it is described here:

Also, if you have had unwantes folders and files in cache, then you should check you installation. Alec is much better in giving advice about this.

Hi @r2d2,

PHP will have different behaviors with respect to permissions depending on what your SAPI (Server API) is – mod_php, FastCGI, etc. See the FAQ entry on permissions for more information. But in any case, it shouldn’t be necessary to set the other-writable bit.

Regards,
Alec Smecher
Public Knowledge Project Team

Once again, I post the question about building a utility that can be run against existing OJS installations. There seem to be many different possibilities for file configurations and rights. A simple tool so check and list vulnerabilities would be welcome.

Could someone confirm that if article submission is turned off that the vulnerabilities described are not existent? Thanks.

Hi @radjr,

We can’t reliably do that – there’s no substitute for understanding what OJS requires of a server and how the server is set up, unfortunately. If the file permissions are not set according to the FAQ entry, we can’t guarantee that OJS is secure.

Regards,
Alec Smecher
Public Knowledge Project Team

Alec, I respectfully disagree. We wrote many test utilities in our SQA departments to test all sorts of functionality and security holes. (Many moons ago!) It would be like stripped down Microsoft Best Practices Analyser that we run on our MS servers.