When checking the submissions folder, I realized I almost got a defaced site. After checking the .phtml files, and trying to run them from a VM, it is apparent that the links the .phtml files referred to are dead, and much of the code is rendered obsolete (also a few typos here and there), so that’s probably why the attempts didn’t work.
So the site survived. But now I don’t know about the integrity of everything. There might be backdoors.
Asmecher have frequently suggested that victims of defacing should revert to the original .tar.gz OJS code. I am willing to do this, but currently there are several submissions in review, and coordinating everyone doesn’t seem good at the moment.
What solutions do I have, so that the .tar.gz file can be reuploaded, but credentials and the processes stay the same? The databases don’t seem affected by the attempt.
Also, at the moment I couldn’t yet upgrade to OJS 3.x, because of bureaucracy.
If you’re seeing .phtml files or similar uploaded to your files directory (that’s files_dir in config.inc.php), then someone is trying to deface your site. However, they can only invoke these malicious files if you’ve misconfigured your OJS by putting your files directory inside the web root where the files can be accessed directly by constructing a URL to them.
If your files directory is located outside your web root, or protected from direct access using e.g. a .htaccess file, then the malicious uploads cannot be invoked and aren’t a danger to your site.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher They’re out of the web root now, but it wasn’t before. Before it was in the same folder as the OJS files (within the OJS directory) and not parallel to it. The .phtml codes merely didn’t run, it seems, because the code is buggy due to age (or maybe, for some reason, the hackers didn’t invoke it directly after uploading it). So the site survived but now I’m worried about backdoors. In other instances of the same deface attempts, you mentioned that one should revert back to the original OJS .tar.gz files, but I’m not sure how to do this in a way that wouldn’t compromise existing submission processes. Our installation is not large but coordinating everyone, including reviewers outside the university, would be a hefty task. The databases aren’t damaged if that’s any help.
Also, what should permissions be? I’m on a shared host with other web domains. So far the files_dir is 0750, but the insides are all 0755. The actual OJS data directory is also 0750, but the directories inside are 0755 too. Files are all 0644 if that helps.
The orthodoxy in dealing with a potentially defaced site is not to trust any of the contents, even if it looks like the hack was never properly invoked.
I would suggest using the standard diff tool (or similar) to compare your codebase against the official OJS 2.4.8-3 release, e.g.: