Our site, and by consequence all our journals, was taken down by our service provider due to “potentially suspicious traffic” and have listed two files as being “infected”:
/lib/pkp/controllers/modals/publish/PublishHandling.inc.php and /lib/pkp/plugins/metadata/dc11/PKPDc45MetadataPlugin.inc.php
The site was running yesterday, but the day previous I did notice that our config file had been altered and a new files folder had been added in root. I changed config back and the site was back up. To me it looks like the two files mentioned above shouldn’t be there. Have we been hacked?
Best regards
Geir Rosset Oslo, Norway
And btw. Yes our files folder is in the webroot, but that is because one.com who is our provider just gives us a webroot and no root folder outside this. I’ll ask them how we can change this, but it might mean we have to use a different hosting product alltogether.
Hi @geirrosset,
Can you also indicate which version of OJS you are using?
-Roger
PKP Team
Hi @geirrosset,
Yes, you’ve almost certainly been hacked using the unsafe files_dir deployment. It is just a matter of time if your OJS/OMP/OPS is deployed with the files_dir inside the web root without protection. (That’s why we have warnings in the installation form, documentation, and elsewhere.)
If your host doesn’t allow you to store anything outside the web root, you can still protect yourself by using a mechanism like .htaccess to prevent direct access to files in the files_dir.
In the meantime, your clean-up is going to be roughly the same as for any web application (like Drupal or Wordpress). Essentially you’ll have to review everything to make sure it’s not been modified, but there are tools to help with this. There are some suggestions in the forum e.g. on this thread.
Regards,
Alec Smecher
Public Knowledge Project Team
We’re on 3.3.0.9 I believe.
Using Htaccess to prevent direct access to the files folder might be a good option, that way we could keep our current plan. Also we’ll be restoring from a backup from about 1 month ago, and we’ll try using diff to check against a clean version to be sure. All suspicious files I’ve seen so far have a certain date, so I’m confident backtracking 1 month will be sufficient.
Sound OK to you?
Not well versed in htaccess rules. Reading up on the subject I see several suggestins on similar issues where the solution is to put an htaccess file in the folder in question (in our case the files_dir) that has the following lines:
Satisfy all
Order deny,allow
Deny from all
ErrorDocument 403 “Direct access to this folder is prohibited”
The first two in case a higher up htaccess file has set different rules.
Will this be a safe way to do this when we do not have a root folder outside webroot?
Hi @geirrosset,
That looks ok to me, but please make sure to test it!
Regards,
Alec Smecher
Public Knowledge Project Team
I did upload the same htaccess file to a test folder on the same server. A sample jpg in that folder was then no longer accessible. Will this solution be as secure as putting the files folder outside the webroot?
Also. What about all the other files and folders. There are 18 folders in the ojs installation. Why is the files folder the only one that is specifically mentioned as far as making it secure?
Also regarding the files folder: When we get our service provider to restore a backup from before this problem arose, and we have installed a fresh copy of ojs 3.4 which we were planning to anyway, how do we know that there are no backdoors somewhere in the files folder which we will have to move or copy back across along with the public folder and the config file? There is no files folder to run a diff command against, and there are 25 000 php files in that folder alone.
Hi @geirrosset,
The files directory is the only place where unprivileged users can upload arbitrary files, so it is the only one that needs extra protection.
Protecting the files_dir from direct access using a .htaccess file should be secure (if you have tested and ensured that direct requests for it are rejected as expected) – we don’t 100% recommend that approach as not all servers behave the same way with .htaccess files, depending on the server technology and configuration, so we can’t give an easy recommendation that’ll suit everyone. And you’ll have to make sure you don’t at some point remove the .htaccess file during some kind of maintenance.
Regards,
Alec Smecher
Public Knowledge Project Team
What about my last question? After we get the site restored, how do we know if there are arbitrary/harmful files in the files directory? Or doesn’t it matter because it has been protected and any harmful file can’t be accessed or run anyway?
As a followup our hosting provider FINALLY got back to us saying they had restored the webroot to an earlier date, but they had just overwritten the current files with old copies which means all the malicious files were still there in the folder structure. Geniouses.
Hi @geirrosset,
Even if the files directory contains malicious scripts, it’ll be impossible for would-be hackers to invoke them to cause damage once that directory is protected from direct access.
We want OJS to be able to support journals that legitimately work with e.g. PHP code as part of submissions – think of code review in statistical analysis, for example. Preventing the upload of PHP code entirely would prevent that kind of workflow. So we have opted to permit uploads of files of any type, but to protect them so that they can’t be invoked on the server.
Long story short, once the files directory is protected from direct access, you shouldn’t need to worry about its contents.
Regards,
Alec Smecher
Public Knowledge Project Team
Finally got a backup in place. Everything looks good, and the htaccess file has been placed in the files folder (no access outside webroot yet).
Just to be clear. With the htaccess file in the files folder all sub folders are also protected?
I tell you, with all hosting support dependant on email what would have taken 10 minutes if talking to an IT tech on the phone has taken the better part of four working days. Hooray for outsourcing.
Hi @geirrosset,
I’m hesitant to give specific advice on working with .htaccess files, as they’re a feature of your web server, not of OJS, and web servers differ in behaviour. But yes, in my experience using .htaccess files protects all subdirectories as well. You can double-check by trying to access a specific file by path and filename after the .htaccess file is in place.
Rergards,
Alec Smecher
Public Knowledge Project Team