Our Joomla website has not been touched by us in a while. When I went to add new content, we have the following problem. The initial page displays fine, but whenever you click on any menu item or link we get the following russian text displayed:
Файл ключевиков keys/sharperdevelopment.com.txt пуст или не существует. Пропишите туда хотя бы один ключевик.
Which translates to:
File keywords keys / sharperdevelopment.com.txt is empty or does not exist. Prescribe to at least one of keywords.
Does anyone have any clue as to whether this is a hacking problem or a configuration problem? A view source on the web page shows no other HTML just the text shown above.
Our Joomla version was just upgraded to: Joomla! 3.4.8 Stable
The website is SharperDevelopment.com
And of course this is happening just before we are meeting a new potential client. Any help or suggestions would be appreciated.
If your website has been hacked previous to the update, you'll need to comb through the file system for the files that have been modified and/or added.
Uploading a fresh copy of Joomla 3.4.8 will not resolve this problem.
I'm going to assume linux because that's when I run on. I manage multiple LAMP servers each hosting multiple domains.
Save a backup and mark it as infected. Do this because the site is working although infected.
first things...
run tail -f path/to/logs/* | grep POST
You need to see who's posting to odd files on your website.
Turn off word wrapping.
Each find that gets posted to needs to be visually looked at.
joomla files start with <?php\n then comment header. If you see a string of PHP code, you need to remove it.
here's a list of some files posted to that I see a lot.
nnnnnnnnnnnnnnnnn.php
alias.php
article.php
css.php
blog66.php
defines.php < Joomla file that has been modified.
dirs.php
footer4.php
functions14.php
global.php
lib87.php
trust.php
functions.php
/includes/defines.php shouldn't be a long file. if you see //istart then you need to remove everything from that point on.
you need to grep for files that use eval or GLOBAL. istart should also be checked. These commands will most likely output a lot of data so pipe it to less.
find /home -iname \*.php | xargs pcregrep -M "^<?php.*\n.*fun"
find /home/ -iname \*.php | xargs grep "eval("
find ./ -iname \*.php | xargs grep "globals"
Pipe to less works like this.
find ./ -name \*.php | xargs grep -r "eval(" | less
grep -r "eval(" | less
You'll be looking for files that contain encoded strings like this but longer: (code posted is not valid) 1ktebHkKHMh7oMftoPA4evcfEoVJs4sUmcTtLCl5Jq0IGoKAUnbzDC1f6C2rJpduyVxvDvRsEztPwSUb6ey73tAVtx8A6BPK+SwyqR/edx3BsfPnmsfbwCFG2kYk
Many times the file will end with eval base64_decode and gzuncompress.
Many legit files use eval and base64 decode. If you see a really long block of encoded data, it's most likely a malicious file. After a while, you'll be able to see patterns that don't look right.
Some files may have the user agents for google bots also. I've been seeing this recently so look for the string googlebot
grep files for the following strings too.
74.125
lnkfarm.pw # this is an actual host. It has been reported to Interpol
You can make a backup of any files you got and check them against joomla's github repo.
https://github.com/joomla/joomla-cms
Also check mailq for deferred messages that are cause by spam bots, that's what many of these files are used for..
I also added iptables rules like the following to stop it initially.
-A INPUT -p tcp -m tcp --dport 80 -m string --string "POST /libraries/joomla/exporter.php" --algo bm --to 90 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 80 -m string --string "POST /modules/bmvlfj.php" --algo bm --to 90 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 80 -m string --string "POST /modules/7595mb.php" --algo bm --to 90 -j REJECT --reject-with icmp-port-unreachable
There's probably a lot of other ways to search for malicious files but this is the method I have right now.
After you get all the malicious files off, make a backup then update all extensions. I would check your files again after that and load the a fresh copy of the Joomla files onto your website, then search for the oldest files in your web directory.
After you're sure it's all clean, change all your passwords and backup. Do not store the backup locally.
Additional answer, maybe it may be helpful for you:
Your question:
Joomla Site Hacked?
Try Eyesite extension. It takes a snapshot of your J! site directory tree and later, if there is any change, it e-mails you until you reconcile the changes. (How often, it depends on you – you set schedule of checks using cron.) This way you can receive early warning, especially on sites like yours, where there is minimum of changes over long period of time.
I'm curious what you've discovered? I have a Joomla 3 site that started after the 3.4.7 (I think .8 came out very shortly after .7 and I thought it might be a fix). What I learned here >>> http://forum.joomla.org/viewtopic.php?f=706&t=902833
Based on that information, I turned off SEF and the site works fine (well, not fine, because I want to use SEF).
I was concerned about hacked too, but the other posters on that thread seem to think it is a hosting issue (we're using BH).
Update: looks like someone posting after me found the solutions.
http://forum.joomla.org/viewtopic.php?f=706&t=902833#p3352730
This fixed my site. Cheers!
If you run your own server you can monitor for changes to your files in real-time with incrond. You will need to write a script to generate a list of directories to watch:
PARAM="IN_CREATE,IN_DELETE,IN_MODIFY,IN_MOVED_FROM,IN_MOVED_TO,IN_ATTRIB"
CMD='/path/to/mail/script file change detected in: $@/$# with event [$%]|Web files changed'
OUTPUT=/etc/incron.d/www-changes
WEBROOT=/var/www
# generate config
find $WEBROOT -type d -print0 | xargs -0 -I{} echo "{} $PARAM $CMD" > $OUTPUT
If you do not block front end access to directories that should not be browsed you will get hacked period. The following directories should have front end access blocked:
bin|cli|components|includes|language|layouts|libraries|logs|plugins|tmp
You should also disable runnning of scripts in front end accessible directories:
images|media|modules|templates
You can then monitor the error logs with incrond for access to forbidden files & block attackers.
Using the lists from I-Blocklist with ipset will also help. I block approximately 120,000 abusive ip's in a fraction of a second. It is also useful to block tor nodes.
If you use ipset you should place the blocking rules in the iptables raw table for better performance & not the input & output tables as a lot of guides incorrectly show.
Running Hiawatha Webserver as a webserver or reverse proxy will also stop a lot of attacks.
Your /var/www should be mounted noexec,nosuid to prevent an attacker running a script they manage to upload.
Use the chroot functionality in php-fpm to limit the files available to an attacker. To find the list of files needed for dns resolution in the chroot run:
strace php /path/to/file-below
<?php
header( "Content-Type: text/plain" );
echo( gethostbyname( "google.com" )."\n" );
print_r( getdate() );
?>
