“When it all started”, i mean this code injection on a massive scale, two years ago, it was simple to cure, as it was just one piece of code injected at the first line of the .php file. You cured that, secured your site (if they did not get in through a backdoor of a shared server itself) and you were done.. But now, this type of hacking got more sophisticated. With the Timthumb backdoor, I saw how the hackers’ script had found one old timthumb script, and must have “tagged” it, as in the weeks to come, they tried to inject one file with a bit of code. Once they did that, again, they must have flagged it “that they got in”, they executed that code, which did a whole series of operations on my site. They actually created an entire subsite (in a /subdirectory), which was a PC virus injector (infected anyone who visited that subsite).
The moment they had that site set up, they sent out a spam email to a massive list of people, directing them to that subsite.

I got to know about it, as someone went to my actual site, found the “contact me” details and emailed me, warning of the infection. I was able to clean it all up in a few hours, but in the mean time, Google had already banned that subsite as malicious (I admit, they were really quick), and at the same time, secured the email spamming-backdoor from my domain.

I think the time, us webmasters, can say “Oh it won’t happen to me”, is over. The hacking attempts are on such a massive scale, and play that close on the ball that the moment a vulnerability is discovered, as of the next days, their servers start searching for sites with that vulnerability already.

Wish us luck, protecting one’s site will only become more and more difficult.

Peter

Good luck.
-Danny

The cleanup routine is based on the hacking code “signature” from 2 years ago.
it is looking for any file where the FIRST line starts with:

< ?php /**/ eval(base64_decode(

Check the .php files on your server and see which base64 code the hackers have put in your files. IF the hacked files contain a string on the FIRST line of your .PHP file, but it does not match the above search criteria, you need to copy that piece of code and put it into my cleanup routine. Has to be an exact copy.

If your site is hosted by a commercial hosting provider, it might be good to contact their support and ask them to look at your files, and if possible cure them. As we are now 2 years after the first of these hacks came in, most hosting providers have cleanup scripts now... Might be a safier option for you, as in the mean time, hackers have diversified their hack and now inject other code in other places.

If your site was hacked through the timthumb backdoor, you will cure it in yet another way (again, your hosting provider should be able to help you)

Let me know if you need further assistance!

Peter

I’m implementing your fix as we speak. If all goes well, you will no longer see a blocked site. next I need to ask Google to recheck the site.

Thanks,

matthew

Chris,
No, that is not exactly how it works. Some content management systems allow users to upload files e.g. avatars. If a hacker would do that, and know where the file is stored (and hide php code in the uploaded file), and execute it, then he is in.
So you’d have to mimick a user on your site.

To simulate it, though, you can transfer the file to your site using FTP, and then execute it from the directory where you uploaded it.

hope this helps,

Peter

Is this good news, i.e., GD is preventing me from uploading executable php at root?

True too that this script only cures infected .php files, for base64-signatures. There are many other ways a site can get infected.

True too, this is curing, and prevention would be better. I covered a couple of those in another post, but none of them is water-tight.
At the time of the first mass infections, the hackers clearly got in via Godaddy, and got hold of FTP login credentials. Changing the credentials helped many. But the leak did not come from the sites themselves, but from the hosting service (e.g. I never use FTP, only SFTP)…

If you ever come up with a more flexible way to cure, and a more watertight way to prevent, i’d be happy to write a post about it. (and you would help many people along the way too!)

best,
Peter

I’ll have to say that your solution is a cure not the prevention.

I myself am a PHP expert and I have seen the script of fixfiles.php. It only searches for “<?php /**/ eval(base64_decode(" in the beginning of the file and if finds, it lists that as a reported file. But there are so many other kind of malware lines which get inserted at the beginning of the file e.g. "” and iframes also get inserted. This script won’t cure them unless we modify the script a little bit for those conditions as well.

One can set this file execution using cron job and run it daily so whenever the site gets attacked, fixfiles script will fix that. But again, it will just be a cure not prevention.

Godaddy is not that cause of it, there are many other sites hosted on other servers like hostgator, bluehost which are facing the same problem.

A simple solution is to re-upload a fresh copy of your script to the server. But still there are situations where this doesn’t help e.g. if the virus is in the database or in a plugin/extension etc.

I am working on it to find the permanent cure, will get back once done.

Thanks,
Umer