By wcutiew on
I have installed Drupal 6.10 a few weeks ago. From day 2 of installation, my index.php page gets hacked and some malicious code gets inserted. Avast Anti-Virus tells me that the code is a trojan virus.
I delete the file and re-upload a new one, but to no avail - as the variations of this malicious code keep getting reinserted daily. My server log emails me the following in long email:
login failures:
Mar 13 05:32:08 alinka sshd[14137]: reverse mapping checking getaddrinfo for internetmax-200-66-102-164.maxcom.net.mx failed - POSSIBLE BREAKIN ATTEMPT!
My host tells me it's the code's fault - that it's not secure and vulnerable and suggests I delete drupal. But I really like drupal and don't want to delete it! What do I do?
Comments
Internal login compromised.
This happened to me a bunch of times on Servage.net.
There's a sort of problem in that if the attacker has guessed your password and gained ssh access, then they can do anything you can do, and any security you can apply can be undone by someone using your authentication. (or the attack is coming from inside the compromised host itself - which is beyond your control)
ANY system, Drupal, dynamic or static is vulnerable to a security compromise that severe.
The only Drupal-side attack vector is if you have set permissions to all+write on your site files globally. This is wrong, unneccessary, and would be labelled your fault. It would mean that web scripts could potentially be exploited. But the ssh login shows it's not that.
List the permissions you have set on the drupal root directory for more troubleshooting.
All you can do is change your account (not Drupal) password to something highly secure, and pressure the host to ensure a defense against brute force attacks.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
if your host tells you that's
if your host tells you that's drupal's fault....move to another host!!
it is a waste of time to put your system in such a hosting company ..forget it..
great advice
You've got great advice from other folks already. When setting up your site be sure to read the secure configurations of Drupal section of the handbook. When you write modules, themes, or install contributed modules be sure to consider how to writing secure code.
--
Morris Animal Foundation
I just got this last night.
I just got this last night. Had just finished a blog entry and posted it to twitter and a mailing list... woke up this morning and it was hacked. The only thing that was changed was index.php with a hidden div and a massive amount links at the top. It was a stupid place to put them as it slowed the site considerably and created a load of warnings. I suspect this is a drupal bug or some php vunerability (we are on dreamhost - not sure how up to date they are) as a hacker coming in via ssh would have put it in a better place.
Anyway - luckily I went to blog again this morning and saw it so luckily caught it quickly.
I have the latest version of drupal and all my modules up to date with drush. Only about 4 modules installed all pretty standard ones.
drupal does not control the
drupal does not control the permissions on index.php and does not control access to your hosting account. The odds are some has your ftp/ssh login information or has breached the server. In this case the best plan of attack is to change login information for ftp/ssh/cpanel (or whatever control panel is used). Also make sure they did not create addition ftp/ssh accounts. And you can always make index.php unwritable.
It just happened again today
It just happened again today - changed all the passwords yesterday. It's on a dreamhost box... so they only thing else I can think of is that someone has comprimised the dreamhost box. I've set the perms on the file to 444 for now to see if that helps.
I do have other drupal sites with dreamhost - but they are on another server... maybe it is just that server....
:( If your (high strength?)
:(
If your (high strength?) password went again within a day, then someone is inside your box, or has left behind enough backdoors.
If *I* was doing this (I have before for white-hat reasons) I'd suggest you look at your ~/.ssh/authorized_keys
That's the easiest (and most obvious) place to put a trapdoor.
Crap. But what you've got is a sysadmin issue, not directly Drupal. Drupal is just one of the victims.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Steps You Can Take
Although most of my posts generally go unanswered, I feel for those who encounter hacks that result in the WSOD as it can be a nerve-racking feeling. Stay calm. Hopefully, these steps will help you resolve the issue.
the files and upload new uncompromised versions. My preference is to edit the files from my server manually, because I don't like the idea of sending what may be older files from perhaps older versions of the Drupal site onto the server.