Hi, we administer in the servers of our university 5 journals. Recently we suffer an attack that create a different index.php and also change the name of the folder files/journals.
I’m relatively new to OJS and totaly new to this issues of security, but from the things that I already readed and what I see in my apache logs, I can guess that the attack is something related to some kind of exploit or LFI using proc/self/environ method.
There is any report of something like this?
This is a problem related to OJS or some of my configurations?
One thing that maybe could create the problem is that the owner of the files was www-data user.
Hi @malayibiri,
Unfortunately it’s hard to know without more information – but one means of attack that we’re aware of is uploading malicious .php
files as submissions. If your files directory is available for direct access via the web server, it’s possible for the attacker to construct a URL that then accesses the PHP file directly to get it executed. This is not a vulnerability in OJS, but a dangerous deployment. It’s noted on the installation form and elsewhere that the files directory should not be directly accessible; typically you should put it outside the web root or protect it from direct access using an .htaccess
file or similar mechanism.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, thanks for your answer!!!
I can’t tell you more information because of my limited knowledge of OJS and my bad english. But I think you are right, my files directory was in the OJS root directory and owned by www-data user with 775 permission, that’s exactly the kind of dangerous deployment that you mention, I think. The same was for the index.php file.
Most probably, what happened was that “the attacker to construct a URL…” as you said.
Fortunately the attacker didn’t get access to the db and didn’t delete nothing in the files directory. But any way I decided to write this question here trying to get some hints about security issues in OJS, in order that something like this doesn’t happen me again. Besides the installation notes, there is a wiki page or something explaining this with more detail?
Thanks again for your help.
Hi @malayibiri,
There’s a section in docs/README
that describes a few things to check. For the most part, though, the details will depend on your server – does it use mod_php
, CGI, FastCGI, etc? Does it use SELinux, open_basedir, mod_security, etc? Unfortunately there are too many deployment possibilities for us to be very specific.
Regards,
Alec Smecher
Public Knowledge Project Team
ok
when I finish to confiure the server, probably tomorrow, i will post here all the configuration and server characteristics, maybe then, if something is wrong, you (or any) can point it out; and then, of course, maybe this question can be usefull to someone different than me
thank you very much for your concern.
As I said in the previous message, I’ll put my server configuration here, maybe someone can criticize/suggest/recommend something that could be usefull.
But firstly, I should say that we receive an attack, some kind of Local File Inclusion with proc/self/environ. I can’t reproduce the attack (I’m far from been a hacker). But actually, from the readings of the logs, I’m almost sure that the reason why this attack worked, was that the “files” directory was in the OJS installation and accesible via web server, exactly the kind of dangerous deployment that @asmecher has pointed out. So, if someone is reading this, yes, “Install OJS so that the files directory is NOT a subdirectory of the OJS installation and cannot be accessed directly via the web server”, is no a useless recommendation in the docs/README.
Well, regarding my server configuration, here it is, the question should be, is this secure, it is “too much”, is something important missing?
OS - Ubuntu 14.04 LTS:
- disable root login
- install apache, mysql, php
- disable unnecessary services
- install and configure AppArmor (since I read that Ubuntu use this by default instead of SELinux)
- enable and configure ufw (allow http, https, smpt, ssh)
- install and configure rootkit checkers (rkhunter, chkrootkit)
- install and configure Logwatch
- install and configure fail2ban
Apache:
- in /etc/apache2/apache2.conf
Directory /var/www/html>
Options -Indexes -FollowSymLinks -Includes -ExecCGI
… - in /etc/apache2/conf-enabled/security.conf
ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None
uncomment other directives in this files - install and configure ModSecurity
- install and configure ModEvasive
MySQL:
- in /etc/mysql/my.cnf
bind-address = 127.0.0.1
PHP:
- in /etc/php5/apache2/php.ini
disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off
OJS:
- do exactly as docs/README says