Dear Friends,
Our site got hacked and google site search lists 1680 pages with Japanese font.
From the forum discussion I could able to understand that it has happened to many others.
I went through the discussions and I prepared to upload the fresh codes in web accessible folder and files_dir in web inaccessible folder. Also set the SH1 in place of MD5.
Now the question is what about the Database? From google I could able to understand what happened to my site is URL injection. Whether URL injection will affect Database too? If yes, how to clean the database?
Also I came across one more terminology “SQL injection”, but from PKP FAQ I learnt that ojs is immune to such attacks (I do not know - Is it true?)
{How secure is the Public Knowledge Project’s software? from https://pkp.sfu.ca/wiki/index.php/PKP_Frequently_Asked_Questions]
You were probably hacked via a submitted phtml-file. After the hacker is able to upload such file to a web accessible folder she can do pretty much anything. The solution to prevent this is easy: keep you files directory outside your web root.
SQL injection means that there are vulnerabilities in the code enabling the hacker to run SQL commands through for example a form field. This is possible if the input is not properly sanitized but I have not seen a single case where a SQL injection has been successful in OJS. Basically all hacked installations mentioned here involve a misplaced files folder.
In my opinion the best solution would be to first look for the phtml-file and find out when it was uploaded. After that I would get a backup from the service provider prior to the hacking, both the files and the database and use those. Of course not all service providers offer backups.
If you can not get a backup, then you should use files from a fresh OJS package. With the database things are a bit more difficult. I would be especially careful with user passwords and ask at least all editor level users to change their passwords asap. I think that setting a new encryption to passwords was actually a very good idea, because now the users have to change their passwords. @asmecher can probably give more instructions on what to check with the database.
Also @asmecher I think it is important to notice that just a little over a day ago @drvenkatesanj was asking about the correct place for the files folder here at the forum. So I think it is very likely that the hacker is reading the forum and hacking installations that are mentioned here. That said I would instruct all users who want to ask about the location of the files folder not to mention too much details about their site here, especially not the URL.
It’s possible that someone is watching here for sites that have accidentally exposed their files directories, but I think it’s more likely that the attack has been automated. That’s a fairly standard approach for known security vulnerabilities.
Just to be clear, you should never put your files directory (files_dir in config.inc.php) somewhere that will allow its contents to be accessed directly through the web server. You can protect it either by putting it outside your web root, or by using a mechanism like .htaccess to prevent contents from being accessed. The risk here is not just scripts like .phtml files – it’s also that legitimate user-submitted content (like word documents) can be downloaded by anyone without needing to be published through OJS first. See docs/README under “recommended configuration” for more information.
As for your database, I think the likelihood of risky content there is lower. The safest approach is to assume that nothing is safe, thus reverting to a safe backup is the only way to be really sure. If you can’t or don’t want to do that, then you’ll need to consider 1) what kinds of risky content might exist, and 2) the likelihood of each being used.
Because OJS escapes unprivileged content before presentation, and does not store e.g. .php code in the database, it’s not a particularly attractive target for attack. Certain roles (Site Administrators and Journal Managers) are allowed to enter raw HTML that isn’t escaped upon presentation, meaning that a malicious user could potentially enter Javascript in the journal settings to cause it to be delivered to users for execution in their browsers.
One option would be to compare your current database exhaustively against a backup version. There are many ways to do this, but I’d recommend something like…
Load the backup into a new database
Use mysqldump to create a SQL dump from it with several options to make the comparison easier to read, such as --skip-extended-insert
Dump your live database to a flatfile using the same options
Use a standard tool like diff to compare the two files.
This will allow you to know exactly what’s changed between the two, and will capture any problematic content that’s been added.
I’m not aware of any way to cause 3rd-party server-side code to execute by inserting something malicious into the database, so I don’t think it’s an attractive target.
Regards,
Alec Smecher
Public Knowledge Project Team
You are right. I could able to find the phtml file in the files directory.
I can go with fresh OJS codes, but database means I will be loosing the new issues published recently.
I will try the one suggested by Alec to compare database.
Thanks for your suggestions.
VJ.