Security issue: hacking of OJS 3.0.1 via submission

[Ivanhercaz]

Hi everyone,
The website that I manage has been hacking three times in two months. After the third time I decide to request to the hosting a root cause analysis to know why it happened and because the conference is in the submission phase, so we need a stable website for our authors.

The feedback of the analysis that gave me the security administrator conclude that in one of the OJS installations (the site has two, one in each subdomain) a PHTML file has been uploaded by a user via the submission process. The file was in the a files directory that isn’t located inside the OJS installation, it was outside of the public_html.

I have read that it already happens in OJS 2.4.8. I also read that if the files directory is outside the web access, it doesn’t produce any problem. But, as I said in the last paragraph, it is outside the public_html, so I don’t understand why this script is hacking our website.

The kind of files added to every subdomain/site that I have are html and php files. The script makes useless all the website (including sites where there isn’t a OJS installation).

As temporarily solution, I have closed the registrations in the site where the script was submitted. But I can’t close the registrations in the another OJS installation, because in that moment we are receiving submissions. Could it be possible to stop a submission when someone is trying to upload some file with programming code (html, php, phtml, etc.)? I have read in the topic of the hacking to OJS 2.4.8 that it isn’t possible but I would like that you confirm me that. I am sure that our authors isn’t going to upload this kinds of files, so this kind of files can be limited.

And yes, as I read in the topic that I have mention, it is made by an Indonesian hacker.

Thanks in advance. I await your answers.

Regards, Iván

[Vitaliy]

Greetings @Ivanhercaz,
To disseminate from non-web directory (in case of linux server), there is a need to know user or root password, is’t it?

[Ivanhercaz]

Hi @Vitaliy,
Certainly… I forgot to told you that I delete another files with suspicious names, with the password word, but they were empty. It is very strange. I know that was an error to delete the files without to make a note with its name and content, but I was desperate

I am going to research more about it. I will notify you if I know more.

Regards, Iván
P. S. Nice profile picture

[ajnyga]

When you were hacked for the first time, was the files directory outside the public_html folder?

There is just no way of using a php or phtml file for hacking, if you can not access it via internet. Someone can of course try to upload those files, but can not use them in any way.

If during the first hacking you had the files directory inside public_html, did you check afterwards that there were no changed or added files in your installation? And did you change your mysql password?

[ctgraham]

The core question is not “Can I stop users from uploading executable files to the webserver?”. Users introduce a set of variables that you cannot really control.

The core question is “Can I stop my server from executing user content?”. You control the server, so this goal is actually attainable.

As discussed elsewhere, having the files_dir exposed to the web is a clear vector for a malicious user executing arbitrary content:

• User uploads an executable file
• User requests executable file over the web
• Server executes file based on the web request

This can be mitigated by either:

• Ensuring uploads cannot be requested over the web (e.g. moving the files_dir outside of webroot)
• Ensuring the webserver cannot execute files (e.g. disabling executable handlers for files_dir)

If compromised, a clean server installation is required to ensure that no additional attack vector was installed within the initial attack.

[Ivanhercaz]

Hi @ajnyga,

@ajnyga

When you were hacked for the first time, was the files directory outside the public_html folder?

There is just no way of using a php or phtml file for hacking, if you can not access it via internet. Someone can of course try to upload those files, but can not use them in any way.

Yes, exists the possibility. It was the first time that I used OJS and I make many changes. If there is no way of execute this kind of scripts outside the public_html, yes, the most probably is that the files directory was inside the own subdomain.

@ajnyga

If during the first hacking you had the files directory inside public_html, did you check afterwards that there were no changed or added files in your installation? And did you change your mysql password?

After the first hacking I check what it adds (several html and php files), but I don’t see the most important: the script inside the submissions folder. I am sure that if I had been open-minded when I search consequences of the attack, I had found the phtml script and try to solve faster.

@ctgraham

This can be mitigated by either:

• Ensuring uploads cannot be requested over the web (e.g. moving the files_dir outside of webroot)
• Ensuring the webserver cannot execute files (e.g. disabling executable handlers for files_dir)

All right, @ctgraham. I am going to apply this settings. But excuse my ignorance about how to disable executable handler for files_dir. I am in a shared hosting, would I need to notify my necessity to the host or is any manual way that I could apply?

Thank you very much to all.

Regards, Iván

[Ivanhercaz]

I have changed the directory inside the public_html being sured that it hasn’t got any bad script that could make damage to the website. But, now, when I tried to access to the submissions files I get an 500 Internal Server Error. I imagine that it happens because the location of the files has changed but the links in the database haven’t been updated.

Is there any solution to that or I have to give to the reviewers the docs when someone submit something?

Regards, Iván

[ctgraham]

@Ivanhercaz

But excuse my ignorance about how to disable executable handler for files_dir. I am in a shared hosting, would I need to notify my necessity to the host or is any manual way that I could apply?

Disabling execution of files per a directory will depend on your server configuration. For example, if Apache is running mod_php, you can use a apache conf or .htaccess directive:
http://stackoverflow.com/questions/1271899/disable-php-in-directory-including-all-sub-directories-with-htaccess

Exact configurations will depend on the webserver process, and the PHP or other scripting processors. (For example IIS might also be enabling ASP scripting).

@Ivanhercaz

500 Internal Server Error. I imagine that it happens because the location of the files has changed but the links in the database haven’t been updated.

A 500 error probably indicates permission problems after moving the directory. More information will be available in your PHP error log, but my first guess would be PHP open_basedir restrictions. The full path to the submission files is not stored in the database, only the path relative to files_dir. If you change the setting in config.inc.php and if you move the directory to that setting’s location, and if your webserver has r/w access to that location, you should be good.

[Hugo_Carlos]

Hi there! I think we may have similar issue on our OJS (3.0.1 installation). I am just the editor, I don´t know technical details about installing OJS (already reported to my suport I.T. team ), however I am sharing the info I already have about it, maybe it can help. This is the second time that the same user appears “Stephan”, with mail “anonproxy29@gmail.com”, and other required fields filled with “x”.

[ajnyga]

Hi, I sent you a private message concerning your OJS installation.

[drugurkocak]

Hi, the same user has been created on our journal and the same php file named hidden.phtml has been uploaded by this user. As far as I see he’s been unable to harm the system. Of course, the files (upload) folder is outside the web directory. All submissions seem to be in safe.
I may share the php code if anyone interested,
Best Regards,
Uğur koçak

[mslyon]

actually I just found the same issue on my server and it seems the attack is explained here: Deface Method Open Journal System ~ EcaTeam.Com - Eagle Cyber Army

Any idea how to protect OJS against this?

[rcgillis]

Hi @mslyon,

Please see the post above that starts with: "The core question is not “Can I stop users from uploading executable files to the webserver?” (as well as the other advice offered in this post). - this offers some advice on mitigating this issue.

Best regards,

Roger
PKP Team

[mslyon]

thanks. I did that and looks good now.