Phishing attempts in OJS submissions

I’ve got a journal editor here at York University who has received several very suspicious-looking file submissions such as the one screen-shotted below.

Warning signs include:

  • .phtml file format
  • can’t Google the author
  • the title is meaningless in the context the journal (language and scope)

Has anyone else been receiving submissions like this? I’m curious to know if there’s a pattern to who’s being targeted.

yul-screenshot

Hi @tmrozewski,

This is probably an automated script looking for a dangerously-configured files_dir (in config.inc.php) that permits the .phtml script to be executed by guessing a URL that exposes it to the web server.

If you’ve followed the recommendations on the installation form and in docs/README / docs/README.md to make sure your files_dir is outside your web root, or protected from direct access via something like a .htaccess file, you’re not at risk.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks as always, @asmecher. I’ll forward that to our IT team and ask them to double-check that we’re appropriately set up.

The user account left an email address (gmail) that I googled and found linked on a number of hacked sites online. Is it worth reporting this to anyone, or is it a lost cause?

Hi @tmrozewski,

If you think you’ve identified someone to report it to who might not otherwise know they’ve been hacked (e.g. a sysadmin), then they might appreciate a heads-up; I’m not sure I can make a general recommendation about it, though.

Thanks,
Alec Smecher
Public Knowledge Project Team

Got it. Thanks again!

Hi @tmrozewski, if you haven’t already you may also want to set the require_validation setting in your config.inc.php file to “on”. This will require any new registrant to validate their registration via a unique link sent to them via email. they won’t be able to sign in and submit content until they click the validation link. Additionally, if you want to keep your user database clean of failed attempts, you can set validation_timeout to something reasonable like 7 (ie. any account that hasn’t been validated after 7 days is deleted). A few notes about this setup:

  • this will stop automated scripts that aren’t able to check an email account and click the validation link. It won’t stop manual registrations, or any conceivable bot setup that somehow manages to verify registrations (which I’ve never heard of in the wild, but you never know). But it’s been quite helpful in slowing down spam registrations and any sort of lazily-automated access attempt.
  • if you are having problems with email being delivered to users, requiring email validation will of course make legitimate registration more problematic.

Cheers,
James

Fantastic, thanks for the tip James!