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.