web site security

can we really be that surprised by a hosting company that uses sex to sell its services?

i was listening to the replay of the teleconference hosted by WPSecurityLock (with special guests from GoDaddy) in light of the recent wave of website hacks that affected hundreds of sites not once, but twice.  it was actually when they were talking to a customer (one who had been hit twice) that a concern was raised in my mind.  the exchange went something like this:

a GoDaddy representative was on the line talking about ways to protect your site against attack, emphasizing the importance of keeping your software (be it WordPress, Joomla!, or whatever) updated.  — note: for the record, this seems like a lame cop-out.  yes, it’s great to keep your software updated, but when the attack is indiscriminately affecting php files — whether they belong to a known open source software or are completely custom-coded — i don’t see how this has any relevance on the situation at hand.  it should be noted that neither GoDaddy nor WPSecurityLock have been able to identify how intruders were able to access users’ sites and change the file permissions which allowed them to inject malicious code into the php files.  software version doesn’t really have any bearing whatsoever on that. —

after he said his piece, Regina from WPSecurityLock spoke with a customer who suffered in the first wave of attacks — actually the first client that they (WPSecurityLock) fixed, and then fixed again when the second wave hit.  she started talking about how, after the second intrusion, she noticed that all the files were left completely open in terms of file permissions (i.e. 777) and that she didn’t think he would have installed it that way.  he expressed gratitude for having them on his team because he admitted that he had absolutely no idea what she was talking about.

and that’s the problem isn’t it?

GoDaddy and other web hosts are saying you are responsible for your files.  you should know what goes into a WordPress installation so you can identify anything weird that’s not part of it.  you are expected to be familiar with FTP and changing file permissions.  but i think that most people hear “file permissions” and it’s like you’re suddenly speaking like the teachers in Charlie Brown: wah wah, wah-wah wah-wah wah.

godaddy: drunk on the job or just intoxicated by mon--er, success?you need to speak to the lowest common denominator here.  if you’re going to provide 1-click installations for any software at all, you have to make sure that when your auto-installer does its’ job it’s not leaving customers open to attack.  because no one that’s going to use a 1-click installer is going to know anything about FTP or chmod, that’s why they used the installer.  and even some people clever enough to know their way around FTP and WordPress’ patented 5-minute install might not know the proper file permissions for their site and just use 777 because it works.  we are lazy.  we use the same single password for everything we do online.  we can’t be expected by our service providers to be educated on proper security practices and safety procedures.  that’s what the geeks with the smelly t-shirts and glasses that make them look bug-eyed are for (although i wrote about some ways to help make your website more secure on arcane palette on tuesday).  no, it shouldn’t be the webhost’s responsibility to wipe their customers’ butt for them when it comes to securing their site, but neither do i think it’s fair that hosts honestly expect otherwise.  especially if one infected site on a server can spread to any or all the other sites hosted on the same shared server which seems like it was the case for both GoDaddy and Network Solutions.

wait, websites?  i just came for the pornit would be great if everyone remembered to change permissions on their files after installing software like WordPress.  it would be great if everyone knew and used the special extra security tricks WPSecurityLock mentions on the call, on their blog and in their free e-book.  but, i’m looking at you guys here, webhosts: the files may belong to your customers but they’re on your servers.  they, apparently, affect all the other sites on your servers (or have the potential to, anyway).  and you can point the finger everywhere except yourself as much as you like — you can say it’s the customer’s responsibility to keep proper permissions, you can say that old software has known exploits that can be used by hackers and that upgrading your software can even leave artifacts behind from older versions (so that, even if you are upgrading your software, you still aren’t safe) — but none of those things are going to make you any friends.  none of those things are going to make you into the good guy.  you know what is going to make you the good guy?  thinking for your customers.  taking care of the situation before it becomes a situation.  taking the role of assigning and/or correcting the file and directory permissions on a website out of the customer’s hands and taking responsibility for that yourself.  surely, by now, webhosts, you’ve figured out that people aren’t going to do something just because they’re told to do it.  surely you don’t really expect people to walk away from these widespread hacks and say “gee, i guess i should be more careful next time.”  unless that’s really part of the plan: give the user the responsibility, then when the shit hits the fan you can say “well, it wasn’t really our fault, but we can have one of our security analysts fix it for you for $150.”

wait.  nevermind.  i see the business model now.

i wish i could say that i made these pictures up, but this is actually how godaddy markets themselves

Keeping your website safe

class=”aligncenter” Once upon a time, a long time ago, you could buy a new computer and not have to worry about what type of virus scan software you needed to load onto it.  Firewalls were things only extreme geeks and intrepid hackers knew anything about.  Adware, spyware and malware weren’t even words.  Those days are so long ago that high quality, free virus scan software has not only become available, but ubiquitous, highly rated and able to hold its’ own against the big guys (see: Avast! and AVG Free vs. Norton and McAfee).

Just as the innocent days before antivirus software was a necessity are long gone, so too are the days in which website security is something to be considered only by paranoids, security professionals and government sites.  In just the last month we’ve seen WordPress sites on Network Solutions hacked (by gaining access to the database via an improperly secured wp-config.php file), GoDaddy sites hacked and then hacked again (infiltrating and embedding code into any php file — the access point of which is still, as of this writing, unknown), and then Network Solutions sites hacked again (this time by a different method, creating or editing php.ini and .htaccess files in the cgi-bin folder) including several U.S. Treasury sites.

Many of these hacks redirect the visitor to a malicious website which installs malware onto their computer which can then be used to harvest all kinds of information about the user.  Or maybe they inject your computer with malicious software and then direct you to a site that sells you antivirus software (which could, potentially, just be a cover for more data-mining spyware).  Code is indiscriminate — it doesn’t care if your site is high traffic or low traffic.  The attacks against GoDaddy and Network Solutions aren’t necessarily indications that those two webhosts have inferior security practices but rather that someone was able to find a workaround or a backdoor or had some kind of insight into the data infrastructure of those hosts which allowed them to run a script across all the sites hosted by those companies.

The point is, just because you haven’t been affected yet doesn’t mean you are safe.  It’s always better to be one step ahead of the bad guys.  Here are some ways you can keep your website, and the files it contains, safe:

File and Directory Permissions

This is the biggie.  It was due to bad file permissions that hackers were able to gain access to Network Solutions users’ databases last month.  This is also probably the most confusing safety precaution and the one most likely to accidentally render your site completely unusable (at least temporarily).  File permissions that are too permissive will allow just anyone to peek at your files, some of which may have sensitive or secure data in them.  Permissions that are too restrictive can render your site unusable by you or visitors or both.

To make things even more confusing, server permissions are generally referred to by arcane numerical codes or a string of letters, making them hard to understand for a lay person.  Take the time to familiarize yourself with what they mean, it could be the difference between your site remaining secure and having to clean hundreds of php files manually, restore from a backup, reinstall your software or risk losing all your data.

You may see permissions written out like this: drwxr-xr-x.  To a normal human being that just looks like gibberish.  To a server (and an admin or geek familiar with the lingo) the string means that: what you are looking at is a directory (drwxr-xr-x), the owner of the directory (generally the webserver or your own user account) has full read, write and execute permissions for the directory and the files contained within (drwxr-xr-x), the group (generally a server group for clients, or else an application group defined on the server) has read and execute permissions (drwxr-xr-x), and everyone else also has read and execute permissions (drwxr-xr-x).  This directory would be said to have 755 permissions:

   7      5     5
 user   group  world
 r+w+x  r+x    r+x
 4+2+1  4+0+1  4+0+1   = 755

Generally speaking, this is the default setting for most hosting environments.  And, generally speaking, it had the correct permissions to enable 99.99% of web-based applications to run correctly.  However, it does not have an ideal level of protection for anything you want to keep safe.  When WordPress sites on Network Solutions were attacked, it was pointed out that optimal permissions for the wp-config.php file should be 640 or, if that didn’t work with your hosting environment, 644 (in both cases, the execute permission is removed from all user groups — wp-config.php is a file that is read by WordPress, it is not executed, so there’s no need for the x), and in the former case, all permissions are removed from the “world” group, giving only you and your user group read permission (and only you have the ability to rewrite the file).  In most cases, you can safely increase your file permissions to 644, although typically 755 is accepted for directory permissions.

Great.  So what does that mean?

Permissions can be changed in a few different ways.  They can be done from a commandline via an SSH connection to your server, but most people probably don’t do it this way.  Permissions can be changed in an FTP program which you would have used if you uploaded a custom theme to your WordPress site or were responsible for setting up your website.  Permissions can also, often, be modified through the built-in, web-based file manager that many web hosts offer from their admin panel.  If you are using an FTP program like FileZilla, most of the time the option to change file permissions will be available upon a right-click of the file or folder you want to change permissions on, but always refer to available documentation if you have questions.  If you weren’t responsible for setting up your website and you don’t know what your file permissions are set to, contact your webmaster or designer and find out.  If they are too low, request that they change the permissions to something more secure.  Any designer worth their salt should be able to do this for you if they aren’t already (and if they can’t, you can always contact us!).

Learn more about changing file permissions.

Secure Passwords! (or: guest1234 is not a secure password…)

Now that we’ve covered the hard part (and, trust me, permissions is the hard part), we move on the the easier and more manageable stuff.  Like passwords.

You’ve been told this a million times: keep secure passwords.  You’ve been told to “keep your passwords in a secure place”.  You may even have been told never to write your passwords down (on paper or, especially not in a file on your computer).  And you’re wondering how the hell all of these things work together.  Are you really expected to memorize 20 different passwords of 8-16 alphanumeric characters and symbols?

It’s tough.  And most of us use shorthand — one password fits all, and to hell with security.

This is, increasingly, a bad idea.  Actually, this was a bad idea five years ago.  Now it’s a horrible idea.

Face it, we’re going to have to deal with this at some point and it’s better now, when your site is fine, then later, after your site has been broken into because your password for your WordPress backend, FTP and database were all “thomas13”.

There’s a couple different methods for creating secure passwords.  One is a configurable password generator.  There’s various applications you can download, websites you can go to, but the one I’m most familiar with is a plugin for Firefox.  The benefit of using a password generator is it’s completely random, therefore more secure and harder to crack, and in many cases you can specify special characters or not, numbers or not, case sensitive or not — however, the more “nots” you have in the equation, the less secure your password is.  (Even so, “SLKJJHE330” is still more secure than the day you were born and your son’s first name.  Ed. note: that’s not the day I was born or my son’s first name.  Just saying…)

What we used to do when I worked in IT and we made custom Windows install disks or used passwords for different types of apps or servers was take a word or phrase and translate it into L33+ [email protected] (“leet speak”).  Something like [email protected] is easy (easier anyway) to remember and much more secure.  Even better is the fact that misspelling words makes the password more secure!  (Presuming you can remember how you misspelled it…) You still need to be careful the kinds of things you use and try to make it not too obvious.  For example, if you run a blog about your kids, and their names are Antonio and Marie, you probably don’t want to use @nt0n10&[email protected] as your password.  While you could randomize the characters and symbols to change it up, it’s best to stay away from anything too personal as a rule.

Another method I’ve heard of people using is to take a word or phrase and inject symbols and numbers in the middle.  Today’s date is 5/4/2010, and I like Battlestar Galactica, so maybe my password could be [email protected]  Or rather than using today’s date, you could use your anniversary, your father’s birthday, the day you graduated college, anything that isn’t posted on your Facebook profile would probably work best in terms of security.

How do you keep them all straight, then?

So what if you have 5 different sites, each with a unique admin password, each with a unique database password, all hosted on the same server (so, thankfully only one FTP password, but that is different than everything else), how do you remember what’s what?  Well, you could always use the post-it method.  You could store passwords as “Notes” in Outlook or — gasp — save them in a document.  None of these are particularly great, though.  If your house was broken into, someone could easily grab all your post-its and gain access to your bank account, PayPal account, anything you use a password for.  Likewise, if your computer was ever compromised, someone could find the file that contained your passwords.  Anyone who was awake ten years ago or so would remember Microsoft Office “macro” viruses, which would enter through Outlook and then use the connectedness of the Office suite to harvest email addresses and other information from emails, your contact list, Word documents, etc, so if your passwords were stored in a Microsoft Word document, it is possible that all your passwords could be stolen by a particularly clever virus.

The solution?  Well, probably there’s some risk involved with what I’m about to suggest, but there are password managers, often protected by a password themselves, that store all of your various passwords for applications and/or websites you go to.  Many of them are built as Firefox plugins (and presumably Chrome and IE have equivalents out there as well, although I haven’t looked…yet).  This way, all of your sites can have a completely unique, completely secure password and you only need to know the one password you use to access them.  Part of me feels like even having a program like that is like putting the world’s largest diamond in a glass case and making it the centerpiece of a museum exhibit — it’s just sitting there screaming “look at me” — but, assuming you have a secure enough password to access the password manager, and — even better — change it regularly, you’ll be fairly safe, and it may be the best option in light of these new web security concerns.

Keep in mind that to be completely secure, you want your database password, FTP password, and any passwords you use to log onto  your site, or any other site, to be unique.  Using the same password means that a hacker just needs to figure out one to be able to access all of your sensitive data, and you don’t want that.

Be Prepared

So what if your site is hacked and you have no way to recover your data without trashing everything and starting over fresh?

Well, I’m sure you’ve been keeping backups, right?  You haven’t?  Oh, well in that case, you’re in trouble…

A lot of hosts will automatically create backups of all your data.  The timeframe in which the snapshots take place can range from every day to every week to every month.  Even so, it’s not safe to assume your host will have a backup — not all of them do — and even if they do have a backup, it would be beneficial to keep backups yourself, just in case your backup is more recent than theirs, or their servers go down and their backups are lost.

Within WordPress, this can be taken care of by using some highly useful plugins.  WordPress Database Backup is what we use to keep backup copies of the database, although there are others, such as WP-DBManager recommended by WPSecurityLock.  Even if you aren’t a code jockey, able to restore a database backup in your sleep, that doesn’t mean you shouldn’t keep database backups just in case you might need a code jockey to restore your database for you.  Both allow you to schedule backups and have them stored on the server or sent to you in an email.

WordPress itself can always be downloaded from WordPress.org, and that will always be a clean copy of the most recent version.  If you did need to trash everything and start over, that would be the best place to get a clean copy of WordPress.  However, what about your plugins and your WordPress theme?  WordPress Backup backs up your uploads folder, current theme and plugins directory.  Like the database backups, it can be scheduled to back up to the server or email you a copy.  This way, if your site was infected, you would have a clean copy of all the files you’d need to purge to get rid of the virus or malware infestation.

You may also want to consider hiding your site as a WordPress site.  While obfuscation is not necessarily a means of securing your site — especially if that’s the only thing you’re doing — it might not hurt.  A hacker who knows how to get into WordPress could be diverted if, for example, your wp-login.php page was moved to a different address.  Alex Denning of WPShout has some great suggestions of ways to confound potential hackers.

If you don’t have a WordPress site, never fear.  Most popular CMS software that has any kind of development community at all should have comparable equivalents of all of the above plugins.  If not, consider talking to your webhost or hiring a programmer to build a script to backup your database and/or your files and send them in an email.  Neither should be particularly difficult and could be run in a cron job (presumably they’d know what that means even if you don’t).

Make sure you are safe

In both the Network Solutions hack and the GoDaddy hack, it was my antivirus software, Avast!, which first alerted me to a problem.  Having an A/V program that has a realtime web scanning component is incredibly beneficial to finding an infiltration and protecting yourself from being infected by your own site.

If you’re running a blog, make sure you’re doing something to filter comment spam — it’s probably the easiest way to add some nefarious links on your site from the outside and is usually very easy to prevent.  WordPress comes built in with Akismet which does all the heavy lifting of filtering out spam comments — all you need to do is register a WordPress.com account to get an API key, which I strongly recommend doing.

Also, if you are running a WordPress site (or any web-based software) make sure you keep up-to-date on your updates.  It’s not going to save you from being hacked, but often there are security updates and it’s better to install those sooner rather than later. (That said, it has been suggested that too soon has its’ own risks — sometimes updates have new holes that were missed in the testing phase and may open your site up in new and exciting ways.  I usually check for updates once a month; by then, in most cases, any potential bugs that were serious have been worked out and fixed.)

If you have been hacked, here are a couple links that can help you recover:

FAQ: My site was hacked
How to completely clean your hacked WordPress installation

Web security isn’t going to go away.  These mass website hacks are not going to go away.  And it isn’t fair to assume that your host is going to be responsible enough to protect your site in what is, in their eyes, your responsibility.  Even if you have a retainer who manages your website(s), you should still make sure you are aware of what is going on in the outside world and make sure they know what’s going on, too.  A good thing is having your tech or designer fix your site in a matter of hours after you report that there’s something fishy on your website.  A better thing is having your tech contact you first to say “there’s a hack going around, I’ve taken precautions against it, and I’m monitoring your site in case of an attack.”  You don’t want to be the one left behind with the guy who says “um…what?” when you say you think your site has been hacked, whether that guy is your “web guy” or your hosting provider.


GoDaddy-hosted sites at risk — WordPress, Joomla!, Pligg, ZenCart, others…

Recently, there was a malicious attack on GoDaddy-hosted sites. It’s tough to track down the exact date of the original attack — I was first able to find a mention of it on Slashdot from 4/26, and I found a topic in the WordPress support forums that supported that approximate time. However, I also found another post elsewhere with a Unix/Linux shell script that would fix what appears to be the same issue which was dated March 2, so this may have been around much longer.  At any rate, there seems to have been another major wave this past weekend.

Last month, Network Solutions was targeted by what appeared to be a malicious user who was able to gain access to sites’ databases by accessing the database server, username and password from the wp-config.php file common to all WordPress installations.  The attack took advantage of the fact that most users don’t change their file permissions, and left the wp-config.php file — with all the above information that it contained — in a public-readable state.  Once the database username and password were obtained, the hacker added a redirect script in the Site URL setting in the options stored in the database which redirected visitors to a site of his choosing.

This taught us the lesson to make sure your files — especially the important files with sensitive data contained within them, like passwords — are properly secured by correct file permissions.

This particular hack on GoDaddy sites did not attack the database, the upside of which means your data, stored passwords, posts, and everything else are still safe. However, according to the reports I found, what it did was embed a small javascript at the bottom of every php file.  The embedded code would ultimately cause visitors to be redirected to a malicious site that would install malware on their PC.  Based on the domain names that were grabbed by an independent security analyst, it looks like the end-goal was to infect a visitor’s computer with malicious software or viruses and then sell them antivirus software (the virus-scanning effectiveness of which would, presumably, be fairly suspect, given the circumstances) — the domains were things like safelinkhere.net, cleanupantivirus.com, letme-guardyourzone.com, systemmdefender.com, etc.  That post also points out that the person or people behind this attack have done this before.

So you have a GoDaddy site running WordPress, how do you know your site is infected?  If your site was infected, you would see this when you logged into your dashboard:

At first glance it just looks like the CSS is messed up, not anything that might suggest a virus.  However, when I tried to access the admin panel on two GoDaddy-hosted WordPress sites that we support, my antivirus software gave me a virus warning.  This happened, too, when the Network Solutions hack went down, so I became instantly suspicious.  (My virus software, by the way, is avast! which can be downloaded free for personal use.)

GoDaddy’s official initial response to the issue — which has been posted in a couple different places — was this:

A few of our customers were affected. Here’s what our CISO had to say 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.

This underscores the importance of installing the latest Web applications, no matter where you are on the Internet. If you use Hosting Connection, automatically update WordPress to version 2.9.2 using the simple 3-step update offered when you log-in.

And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure, and in a safe place.”

If you have questions or you’d like someone to take a look at your WordPress site, please get in touch with our 24/7 support team at http://fwd4.me/MBI


Here’s the problem with that statement: it’s wrong.  Both the sites that I saw directly were running the 2.9.2 version of WordPress.  And I’m not alone.  I’ve read reports in forums and blog comments from many users who were not only running up-to-date versions of WordPress, but also had secure and unique passwords for their WordPress backend, FTP and database, and many had countermeasures in place to prevent attacks on their WordPress site.  None of which protected them from being infected.  Later, GoDaddy’s Chief Information Security Officer sent out the following message which is currently appearing on their support page:

If you are experiencing difficulties with your site, you may be using outdated software and unknowingly hosting malware…And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure and in a safe place.

Calls to GoDaddy support about the issue right now are apparently being met with “this is a WordPress issue”-type responses.  But careful viewers of how this particular infection works will see that there isn’t anything specific to WordPress about it — it’s targeting php files on GoDaddy-hosted sites.  Whereas the Network Solutions hack was looking for a specific file — wp-config.php — to gain access to the database, php files can be in any software written in that language, which includes Joomla!, Drupal, ZenCart, Magento, and on and on.  Blaming the issue on bad security practices is a gross misrepresentation of the facts. As of this writing, GoDaddy hasn’t yet tracked down the source of the infiltration or taken much more responsibility for the issue than the above statements.

The good news is that, as far as I can tell, there isn’t anything you did wrong to make your site more of a target. The bad news is no one is sure how the hacker was able to access a huge number of sites on GoDaddy and append a javascript code at the bottom of every php file on those sites. The fact that GoDaddy’s canned response inaccurately suggests that the affected installations were outdated isn’t very reassuring.

Fear not, for there is a fix.  One thing the infected sites seem to have in common is that they are all hosted on Linux servers.  If your GoDaddy site is hosted on a Linux server, you can use the History feature to restore an earlier backup of the files. Since the database was untouched, this won’t affect any posts you may have published, however it may (or may not) affect any media files you uploaded between the time you restore back to and now — so it’s probably a good idea to check those posts for broken image links and the like after you do it to make sure everything is okay.  Check out this help file for full instructions on how to restore your site to an older backup.

Over the weekend, GoDaddy posted a fix to their forums that they referred to as a “permanent” fix. The updated fix involves backing up your database, saving any files you may have uploaded to your site, deleting everything, then reinstalling and restoring your database backup. While this would resolve the issue, until they announce that they know where these attacks are coming from and why they are so widespread, I can’t see this as a “permanent” fix — it’s not any more permanent than restoring from a backup (presuming that the virus wasn’t present at the time the restore point you are using was created).  And evidence suggests that security best practices wouldn’t safeguard your site against attack either.  That said, changing your passwords is probably not a bad idea.

I would like to reiterate that this is not a WordPress compromise, but a GoDaddy compromise. In this case, the sites that were reportedly vulnerable (those that were using a version of WordPress prior to 2.9.2) was inaccurate and given the nature of the attack, I don’t see what the WordPress version really has to do with anything anyway.  Even if we assume the attack only targeted WordPress, 2.9.2 addressed an issue in which users who were logged into the admin panel could look at Trashed posts from other authors. 2.9.1 resolved a number of minor bugs but no security holes. Neither of these would have prevented someone injecting malicious code into the php files of your WordPress installation. Until someone is able to expose the breach, I’m not convinced that any of the posted resolutions and prevention methods are “permanent” nor do I believe that this is the last we’ll see of this attack — from what I’ve been able to gather, many bloggers who fixed the problem last week were hit again this past weekend. (Not surprisingly, domain transfers from GoDaddy to another registrar quadrupled in the last week of April. This doesn’t necessarily mean hosting went with it, but I’d be surprised if the two things weren’t related.)

I don’t like to tell people that you shouldn’t use a certain webhost because of x, y and z. I will make recommendations based on my personal experience and suggest hosts that I’ve had good experiences with, but I’m not one to badmouth other companies to our clients or their decision to go (or stay) with that company. So I’m not going to tell you to switch to something else if you are using GoDaddy. However, if I was using GoDaddy, I’d be very concerned about my site’s security if it was running any kind of web application (blog or forum or CMS, WordPress or otherwise) until their Security team says something other than “make sure your passwords are secure.” What’s more, while Network Solutions was able to respond to, and secure the attack on their hosted WordPress sites within 24 hours (at least the initial attack, if not the subsequent attacks that came later), GoDaddy was hit with this, initially, sometime around April 21 or even much earlier.  I’ve seen no indication that they resolved the initial breach, let alone these new modifications.

If you have been compromised, or you are concerned about being compromised, I urge you to contact GoDaddy and express your concerns and try to learn what they are doing to prevent this attack from happening again. The more concerned customers they hear from, the more urgent the issue becomes and, hopefully, the faster they will work to resolve it.  However, if you would rather not be at risk just waiting for this weekend and the next wave of attacks, we highly recommend 1and1 for web hosting, and if you have questions or concerns about your site, you can contact us for a quote.  We can fix your infected WordPress site, help with your webhost transfer, or clean your infected php site that uses a different platform.

Tomorrow I will be posting an article about what you can do to keep your website as safe as possible.

If you would like to learn more about the issue, here are some of my sources:

Massive Number of GoDaddy WordPress Blogs Hacked [slashdot]
Warning! Massive Number of GoDaddy WordPress Blogs Hacked This Weekend [BlogcastFM]
GoDaddy/WordPress ninoplas Base64Virus and the Fix [inspirated]
GoDaddy WordPress blog hacked [WordPress Support Forums]
What people are saying about “GoDaddy WordPress” [Twitter Search]
GoDaddy Hacked WordPress Hosting Accounts [Smooth Blog]
WordPress on GoDaddy.com Hacked [NeoWin]
WordPress Compromised? How to Fix It! [GoDaddy]
GoDaddy Support [GoDaddy]
WordPress 2.9.2 [WordPress Development Blog]
WordPress 2.9.1 [WordPress Development Blog]
Restoring a Linux Hosting Account [GoDaddy]
GoDaddy Domains Lost by Transfer QUADRUPLE!! [NoDaddy]
Registrar Report for GoDaddy [WebHosting.Info]
Ninoplas Base64 WordPress Hacked on GoDaddy [WPSecurityLock]
Cechriecom.com.js.php – WordPress Hacked [WPSecurityLock]
GoDaddy’s Mass WordPress Blogs Compromise Serving Scareware [Dancho Danchev’s Blog]
Breaking News!  Dangerous Malware Alert — Self-Hosted Sites on Major Hosting Service Hacked Again! [WPSecurityLock]
Details on the Network Solutions/WordPress Mass Hack [Sucuri Security]
The Kneber botnet – FAQ [ZDNet]