Hosting With GoDaddy? Might Want To Rethink That Decision.

One of the services I offer people is cleaning their WordPress installations of hacks and infections, mostly for those who might not have the time or technical expertise to follow my hacked WordPress cleaning guide. Therefore when something happens that increases the number of people getting hacked, such as when a new exploit is discovered, or a security hole in a large host starts getting exploited (like what happened with Network Solutions last month), I get an increase in the number of people requesting help cleaning things up. This month it started happening with a large number of GoDaddy customers.

When it first started to happen I did some searching around, and noticed that there was some discussion going on about the heightened GoDaddy hacking activity, but at that time everything I read that stated the problem was with GoDaddy customers all had roots pointing back to a single post on a company blog that didn’t offer enough details for me to really see why it was happening there and not other places. Not that WordPress on other hosts weren’t still getting hacked, but there has definitely been a higher concentration of instances on GoDaddy. GoDaddy was definitely aware of the issue, and even replied in some threads on the WordPress.org help forum:

GoDaddy.com did send out a notification to customers affected by this issue. Although I know you would prefer not to be linked, I want to avoid flooding the forum. For a step-by-step guide to update WordPress, please visit http://fwd4.me/NGNAlicia from GoDaddy.com

The link to their “step-by-step guide” to updating WordPress turns out to be nothing more than than a link back to WordPress’ own guide to upgrading, and links on how to back up your stuff on GoDaddy. Decidedly not step-by-step imo, and in this case not all that helpful. If the reason your site gets hacked is due to you running an older, insecure version of WordPress, once that happens simply upgrading will not fix the issue. This seems to me to be a bit of a lame response to a serious issue coming from a company that bills itself as the “World’s largest Hosting Provider”.

GoDaddy keeps insisting that the problem is due to outdated WordPress installations, and that staying up to date and site security is the responsibility of the customer, not of GoDaddy. In one sense I completely agree with them. If you run an older version of WordPress that has known security holes in it (ie. pretty much all versions aside from the most recent) then the odds are that you are going to get hacked. Most of the clients I cleaned from GoDaddy so far were up to date, running version 2.9.2, but this still didn’t mean that it was GoDaddy’s fault, since it is possible for a site to get hacked and no signs show up for months. This means that the sites I was cleaning could potentially have had the hack from an older version, and it only became apparent some time after they upgraded.

The problem is that after doing some very thorough clean up jobs (ie. wipe and reinstall), and making sure the clients were up to date, all passwords changed, all image files verified as actual images, clean WordPress, clean theme, clean plugins, and hand cleaning the database, I had clients still getting re-hacked.

One client I had was having issues with funky characters in his posts. He would make the post, everything would be fine, and then the next day they would be converted in a way that would make them display as unicode. This was well after I had done my cleaning, and no one should have made any changes to the database since then. My assumption was that GoDaddy themselves was making changes, possibly security upgrades related to the recent hacking waves, and I figured that calling them to see what they had done would be the best bet. In preparation for this I went ahead and logged into the client’s account, and ftp’d into the server just to make sure everything looked like it was in place still. As soon as I did I saw that about 30 minutes before a brand new, non-Wordpress, oddly named php file had been dropped into my client’s site.

I downloaded the file and looked at it. I suddenly realized that this was the source file for all of the hacks that were happening. It was named “plan_erich.php”, and had similar eval(base64_decode( instruction at the top of the file. I modified the code to be able to decrypt it safely, and looked through the output (which you can view here). The script was designed to delete itself as soon as it ran:


$z=$_SERVER["SCRIPT_FILENAME"];
@unlink($z);

Finding this script before it was triggered and deleted itself was raw luck. Catching this file gave a great opportunity to actually track down how these hacks are occurring, and possibly would leave clues that GoDaddy could use to keep it from happening again. Looking at the owner/creator of the file, and matching that timestamp up with the various logs (ftp, ssh, http, mysql, etc) could give GoDaddy the information needed to figure out how the file really got there, instead of just guessing that WordPress was the issue. I have never seen a file like this before, and searching Google for the name yielded no results, so there really was no other information out there available on this. Finding it there was a little like hitting the lottery in that respect, random and very, very good luck.

The problem, however, is that GoDaddy didn’t seem to care. I called and explained to the woman I spoke with exactly what it was that I found and how it could be useful. I told her that matching up that file to the logs could yield some potentially valuable information. She did listen carefully, and I am pretty sure she understood what I was saying, because she asked if she could put me on hold to go talk with someone who might know more. She came back and informed me that she didn’t have permission to look at those logs.

I explained again, in a little more detail, why looking at the section of those logs was very important, and if she didn’t have permission could she please escalate the ticket to someone who did. Again, she put me on hold. This time she came back and told me that they were uninterested in escalating it.

At this point I was a teensy bit amazed at GoDaddy’s lack of concern with the issue. She very kindly informed me that the issue was that the client was running an older version of WordPress, and that we needed to upgrade. Wtf? I went and looked, and made sure that he was indeed still running the 2.9.2 version that I had installed over a week ago (and remember, he was running that version before I ever did anything), and he was. I told her that. She told me that no, she was looking at what the hosting control panel said, and that he was running version 2.6.

That was when it struck me… GoDaddy was claiming that this wave of WordPress hacks was due to clients not upgrading without even bothering to really look at the clients sites. The hosting control panel can only report what was installed via the hosting control panel itself. If a client pushes the button to upgrade WordPress from within the WordPress admin section then the hosting control panel will never know.

As amazing as it seems, apparently the entire GoDaddy technical support team is ignorant of this fact. That’s right… the “World’s largest Hosting Provider” doesn’t understand the very basics of how the world’s largest blogging platform works.

Something, probably a hosting configuration, is allowing GoDaddy customers to have their sites hacked, and it isn’t file permissions, insecure passwords, or out of date software. Not being willing to even look when a developer calls to tell you that they found something is completely unacceptable. My suggestion to all GoDaddy hosting customers: bail now, before something happens to your site. This is not a WordPress issue only… although it seems to have targeted WordPress customers first, all sites that use php are at risk. Personally for shared hosting I recommend Hostgator, because I love their tech support (and their servers are very robust), but there are plenty of hosts out there to choose from (Disclosure: I changed the previous link to an affiliate link, although if you’d rather purchase hosting from them without giving me credit that’s fine too, here is a clean link for you: HostGator).

Bob Parsons, I am sorry. Hot chicks and a strong tits and ass marketing campaign do not make up for apathy in matters of client security and well being.

Test of WordPress’s Default Slug Redirect: 301 or 302?

Just a quick test to see if WordPress by defaults redirects slug changes using a 301 or 302 redirect. The original url for this post is:

https://smackdown.blogsblogsblogs.com/2010/03/18/test-of-wordpress-default-slug-redirect-301-or-302/

and I am going to change it to:

https://smackdown.blogsblogsblogs.com/2010/03/18/wordpress-redirect-302-or-302/

Read more

Stray Leftover Hacked WordPress Database Entry: rzf.php

I never use my uploads directory or WordPress’s built in media management here on Smackdown, instead preferring to upload and manually insert the html for images myself in my posts (I know, I am weird that way), but my friend Donna has when she has guest blogged here in the past. I therefore knew that the uploads directory existed and had a few images in there, but never really had any reason to look at them. It was totally by accident that I clicked on the Media link in the admin section this morning. I am glad that I did, however, since otherwise I never would have known that I had missed a bit of leftover data from one of the times that I had been hacked last year, a reference to a file named rzf.php.

I use an early warning hacking detection system that Donna came up with last year with and I helped refine, MonitorHackdFiles, that alerts me whenever there are any files modified or added on my blog. This script has been indispensable in helping me to clean up damage from hacks before either my rankings were harmed or an infection spread to my readers. However, based on the folder structure

Read more

Don’t Think “If” You Will Get Hacked, Or Even “When” – Think In Terms Of “How Often”

The following “guest post” was a comment left on “How To Completely Clean Your WordPress Installation” by a gentleman named Daniel J. Dick. He makes some excellent points, and due to it’s length I decided to feature the comment in it’s own post, rather than approve it in place. Enjoy.

I think Nick sums up how most of us feel about malicious hackers, script kiddies, and spambots that wreck other people’s stuff.

My apologies to everyone that reads this that are searching out how to fix your blog. It is obviously meant for the little, no good, no life having, soulless human maggot out there that creates viruses, malicious scripts and hacks other peoples stuff. YOU SUCK BIG MOOSE C#&@!!

– Nick

Most of my sites

Read more

Is Plagiarism Ok… If It Was An Accident?

Last year I wrote this handy little script named EasyWP. It makes installing WordPress much easier for those without Fantastico or shell access, and is many times faster than having to upload all of the files individually. It’s very useful, especially if you install WordPress on a regular basis, or if you need to do a complete WordPress reinstall for whatever reason. Lots of people use and enjoy the script.

Today I receive this email from someone by the name of Joel Drapper:

Read more

My Blog Hacked, Yet Again – WordPress 2.6.5 Vulnerability / Exploit?

Busted WordPress security. Again, I’ve been hacked. Well, not me personally… I wear the most up to date tinfoil attire, I assure you, and no one is getting into my head… but my blog was. This time I was running WordPress 2.6.5 when it happened.

Those who know me know that I always prefer to do manual upgrades, wiping everything out and starting over completely fresh each time, whether I have been hacked or not. This way if there was an intrusion it should still clean the hack out completely, even if I don’t know it’s there. As it happens, when I upgraded to 2.6.5 from 2.6.2 I did not do this. I merely upgraded the 2 files involved in the security portion of the WP 2.6.5 upgrade (which were wp-includes/feed.php and wp-includes/version.php). However,

Read more