Security problem

Software Support
1

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.

2

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

3

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.

4

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

5

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 :slight_smile:
thank you very much for your concern.

6

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 :slight_smile: