Now, all you need to do is install and activate this plugin, run the scanner from the new Tools -> Timthumb Scanner section in your Dashboard, and click the Fix button to repair any vulnerabilities that are found.

As described on the VaultPress blog, “The vulnerability allows third parties to upload and execute arbitrary PHP code in the TimThumb cache directory. Once the PHP code has been uploaded and executed, your site can be compromised however the attacker likes.”

The folks at Sucuri have constructed a great list of just a few affected WordPress themes, just to give you idea of how many themes use TimThumb.

If your theme uses TimThumb, contact your theme author for an update immediately, or download the latest version if it has already been updated. If your theme author is not willing to offer an update, it’s probably time for a new theme, but you can also get the latest version of TimThumb from its Google Code page.

The presentation is great to watch and quite educational for both WordPress users and developers.

Both releases address three security issues and add additional security enhancements, and 3.1-RC4 fixes “about two dozen additional bugs.”

Both updates are available immediately via your Dashboard, but users updating to 3.0.5 will need to update to the latest release of Akismet again. Core developer Andrew Nacin hopes to minimize “the Akismet update dance” in WordPress 3.1 and put an end to it in WordPress 3.2.

[It] fixes a core security bug in our HTML sanitation library, called KSES. I would rate this release as “critical.” I realize an update during the holidays is no fun, but this one is worth putting down the eggnog for. In the spirit of the holidays, consider helping your friends as well.

If you’re currently testing WordPress 3.1, make sure that you upgrade to the latest nightly release to get the same security fixes.

This release fixes issues in the remote publishing interface, which under certain circumstances allowed Author- and Contributor-level users to improperly edit, publish, or delete posts.

If you have remote publishing enabled on your site you are urged to upgrade. You can do so easily via the built-in automatic upgrade feature. If upgrading the old fashioned way is your cup of tea here is the list of revised files …

wp-includes/version.php
xmlrpc.php
readme.html
wp-admin/includes/update-core.php

The flaw exists because the application does not require multiple steps or explicit confirmation for unspecified sensitive transactions for the admin function. By using a crafted URL (e.g., a crafted GET request inside an “img” tag), an attacker may trick the victim into clicking on the image to take advantage of the trust relationship between the authenticated victim and the application. Such an attack could trick the victim into executing arbitrary commands in the context of their session with the application, without further prompting or verification.

There is no known workaround for versions lower than 2.9.21. Kudos goes to KrebsOnSecurity for reporting the flaw and to bobking who quickly published a new version with the patch.

This maintenance release fixes a moderate security issue that could allow a malicious Author-level user to gain further access to the site, addresses a handful of bugs, and provides some additional security enhancements.

It’s been awhile since we’ve seen one of these types of releases. However, thanks to automatic upgrades built in, upgrading is a pretty easy thing to do.

I have not tested any of these with the latest WordPress 3.0 beta.

Monitoring

In my first article on WordPress security I mentioned Open Source Tripwire as an option for monitoring your WordPress install for unexpected changes. A reader pointed out that it wasn’t the best solution since it’s no longer maintained and suggested a couple other alternatives. Since then, I’ve discovered a much easier way of monitoring your WP install: WordPress File Monitor.

What it does: monitors all the files in your WordPress directory (except the ones you tell it not to) and e-mails you whenever something changes. This means nothing changes without you knowing about it. If someone edits your theme files to include spam links or uploads weird php scripts, you’ll know right away.

Above is a screenshot of the settings I use.

Dashboard Alert: I had this set to yes for a while, but having clear the notification pretty much anytime I made a post (because I upload images, and the sitemap.xml changes) got tedious. Just keep up with the e-mail alerts if you turn this off.

Scan Interval: 30 minutes might be a little too often, I should probably cut this back to something more sane like 2 hours.

Detection Method: My main site is quite large and performance is a big concern for me, so I keep it set to Modification Date. If you’re really paranoid and have a small site, change this to Hash.

E-mail address fields: self explanatory.

Notification format: Detailed. Why would you want anything less?

Site Root: Theoretically, you shouldn’t have to change this.

Exclude paths: I exclude my cache folder (if you don’t use WP Supercache or something similar, you don’t need to worry about this) and error_logs that get a lot of errors. I do have it monitor my Uploads folder in case someone tries to slip an exploit disguised as an image in there somewhere.

AntiVirus for WordPress

I learned about this one from the plugin author in the comments on my original post. As far as I can tell, it scans the core WordPress files and template files for exploits.

You can also have it do a daily scan and send you the results. I don’t do this since I’m constantly monitoring my site for changes with WordPress File Monitor. If you don’t want to monitor every single change in your WP directory, this could be a good alternative.

WordPress Exploit scanner

This seems to do a more thourough scan than Antivirus for WordPress, but I always run into memory problems if I try to run it with the “Files” option checked.

What to do if you’ve been hacked

Detailed instructions will have to wait for a future post. For right now, see the WordPress Codex entry for what to do.

Bonus: greping for great justice

grep is a UNIX command for searching the entire text of a file or files on a computer. If you know the exploit you’re looking for, it’s extremely useful. To do this you’ll need SSH access to your web server, and you’ll need to be comfortable using it.

I had a nightmare of an exploit a while back that I eventually figured out: somehow someone had uploaded a copy of webadmin.php (with a different name so it would be harder to spot) to a few places on my server. They could then navigate straight to that file and change any file on my server whenever they wanted. I found one instance of it and deleted it, and thought that would be that. But I was still finding that my template files were getting edited. Here’s what I did:

1. Logged into my web server by SSH
2. Changed directory to my public directory (you may need to ask your web host where this is)
3. Ran the following command: “grep -r ‘webadmin’ *”

I was then able to locate the file because even though the file had been renamed, it still contained the text “webadmin.” I was then able to delete the file.

As before, I’ll emphasize a few things:

1. Your WordPress security is only as good as the security on your local computer. If you’re not running good antivirus and anti-malware software or are using an insecure wireless connection, none of this will matter.
2. Likewise, if you’re not keeping your WordPress install updated, none of this will matter.
3. I should have at least mentioned this in my previous security article but didn’t: your WordPress security is also only as good as your web server’s security. Since the audience for these tutorials is beginners, I’m going to assume that you don’t have a lot of control over your host’s security settings. So I’m not going to say anything else about this other than to look for a reputable host with experience hosting WordPress.
4. Make sure you’re using a strong password. See step 2 of my previous tutorial.
5. I’m going to assume you already know how to install WordPress plugins.

NOTE: I’m writing this guide for WordPress 2.92, the current stable release. All of these plugins seem to work with WordPress 3.0, but I haven’t thoroughly tested them.

WP Security Scan

Let’s start by checking for the biggest security holes first, using the plugin WP Security Scan.

After you install you should see a new “Security” section on the left column of your dashboard:

Let’s click “Scanner” and check our file permissions, the most crucial of security settings in WordPress. Chances are everything will be shaded green, and everything’s ok. However, if anything’s not set correctly it will be highlighted in red. Changing file permissions is beyond the scope of this tutorial – contact your web host if you need to change anything.

Next, let’s change our database prefix. This is a “security through obscurity” technique. What we want to do is make your WordPress database harder to exploit by using a database prefix other than the default one – this way any sort of generic, automated attack on the database will likely fail because the hacker will be using the wrong database prefix.

BEFORE ATTEMPTING THIS MAKE SURE YOU BACKUP. I can’t stress this enough. I wrote a tutorial on backing up your WordPress tutorial. Even if you don’t use the plugin I describe there, make sure you’ve got a good backup before proceeding.

If you followed my last security tutorial and changed your database prefix during install, you can skip this step.

Otherwise, click “Database” on the Security section. You’ll see something like this:

If you see something other than “wp_” in the field labeled “Change the current” field, then you can skip the next step.

Change “wp_” to something else. It’s highly recommended that you still keep the _ for database readability in the future, however.

Click “Start Renaming”

If this fails, you’ll either have to change the database prefix manually or not at all. Manual changes of the prefix table are beyond the scope of this tutorial.

Secure WordPress

Next, let’s install Secure WordPress. After you install it click “Secure WP” in the settings column of the left column of the dashboard. Most of the defaults should be fine, except one: if you’re not planning on using Windows Live Writer, check the box next to that option and click “Save Changes.”

WordPress Firewall

The steps above will help prevent attacks by hiding information about your WordPress install from attackers, making sure the correct file permissions are set, and plugging a few potential security holes. Next we’ll install some plugins that actually stop attacks on your blog.

WordPress Firewall is a handy plugin for preventing a variety of attacks. This one is especially important if you weren’t able to change your database prefix. It’s quite simple – just install it. There should be no need to change the default settings. Important: WordPress Firewall has only been tested up to WordPress 2.8. It has not been tested with WordPress 2.92 or WordPress 3.0 beta 2.

Bad queries

Block Bad Queries, like Firewall, prevents hackers from performing certain common dangerous actions on your site. This one you just install and activate – there are no settings to change.

Chap Secure Login

If you’re not using SSL to login (once again, beyond the scope of this tutorial), you can use Chap Secure Login to encrypt your password. This is especially recommended if you use a lot of different computers to access WordPress, or frequently use public wireless Internet connections. Chap is another remarkably simple plugin – just install it and activate it and you’re ready to go. Note: you’ll get a warning the first time you login after installing. According the plugin developers, this is to be expected.

Login Lockdown

Finally, we’ll want to protect against brute force or dictionary attacks. In an out of the box WordPress installation, users can attempt and fail to login an infinite number of times. This means someone could try thousands of password combinations until they got the right one. Login Lockdown will ban users from IP addresses that have tried and failed to login too many times.

Install the plugin and click “Login Lockdown” in the “Settings” section. You should get an options menu that looks like this:

If you have a hard time typing your password correctly, you might want to set the “Max Login Retriess” a little higher.

I also recommend using the “Mask Login Errors” option. Normally, if a user types an incorrect username WordPress will return an invalid user name error. But if the user types a correct username but an incorrect password, WordPress will return an invalid password error. This gives someone trying to crack your password an extra hint as to whether they at least have the right username. If you use the “Mask Login Errors” option, WordPress will return a generic “username or password is incorrect” error instead.

Ask Apache

Many people swear by AskApache Password Protect. However, I have not been able to get it to work with my host. Your mileage may vary. If I understand it correctly, this plugin adds an additional password to the /wp-admin directory. If you allow open registrations and have lot of users logging in, you might not want to use this plugin.

Conclusion

There’s still much more you can do, such as using .htaccess to protect directories, moving core WordPress files, and monitoring for exploits. Those are things we’ll have to cover in the future. If you have need to harden things further now, please see the Hardening WordPress Codex entry. Remember no (usable) site will ever be completely secure, but if you’ve installed the plugins above your chances of getting hacked will be greatly reduced.

The way this denial of service attack works is that a random search string is sent to the search form of a WordPress based website. Caching plugins do not work against this because the search string is randomized. It’s quite simple but what I’ve been told is that this is not an issue for WordPress to handle. Instead, this attack should be dealt with by the webhost on a firewall level. At one point, a ticket was created by Scribu but has since been closed as won’t fix.

So at the end of the day, the best defense you have is a competent webhost that will do their part to prevent these attacks from happening. No reason to be alarmed.

While this particular version is relatively simple, the power behind the script and the MySQL database allows the attacker to distribute the attacks not only by sites, but also by passwords tried as well.

The article goes into detail explaining how the script works and suggests the typical security precautions such as using strong passwords, changing the admin username and limiting the admin login page to only your IP address. Brute force attacks on WordPress are nothing new but it’s interesting to see this approach using a distributed technique.

Hat tip to WPVibe.

WordPress is a complex web application that comprises more than 200 .php files. When you open any page, WordPress loads index.php which, in turn, loads many other .php files using the require() function. WordPress admin interface also relies on multiple .php files. In all cases, WordPress loads wp-config.php file which contains database credentials and other important information required for normal operation.

So what happens if both index.php and wp-config.php are infected with the gumblar backdoor scripts? Since Gumblar injects identical backdoor scripts into files on the same site, they’ll have declarations of identically named functions, which PHP doesn’t allow. Hence the “cannot redeclare zsmh() …” error.

One thing not mentioned in the Unmasked Parasites post is information regarding which specific versions of WordPress are at risk or are safe to use. I’ve left a comment on the blog post to try and get an answer but until then, Denis Sinegubko provides detection and removal instructions while also suggesting the use of the WordPress Exploit Scanner which scans for WordPress files for signs of suspicious activity.

Based on the reports of infection, this does not appear to be a WordPress centric issue pointing to a problem with the software.

Unfortunately, the blame game has come back in full force with those affected generally blaming WordPress, and those not affected blaming users who failed to upgrade in a timely fashion. The bottom line is, the issues that lead to this worm attacking older versions of WordPress was fixed in WordPress 2.8.4 which was released on August 12th. When it comes to a security release of WordPress, I take it seriously and don’t mess around with upgrading my site. I think Matt Mullenweg puts it best in his article which explains how to keep WordPress secure.

A stitch in time saves nine. Upgrading is a known quantity of work, and one that the WordPress community has tried its darndest to make as easy as possible with one-click upgrades. Fixing a hacked blog, on the other hand, is quite hard. Upgrading is taking your vitamins; fixing a hack is open heart surgery. (This is true of cost, as well.)

While WordPress has lowered the bar of entry to publishing content on the web, one constant remains, the responsibility of running your own website. This responsibility includes making sure that your webhost is doing its job, that the various layers and technologies which make WordPress tick are fairly up to date and locked down. These layers include but are not limited to PHP, MySQL, folder-file permissions, etc. Dave Coveney also brings up the point that security is more than just WordPress.

Even if you have the very latest version of everything there are, out there, what are known as zero day exploits. These are vulnerabilities which are kept secret by the hackers who have found them. They cease to be secret if they become widely used in a large scale attack. Like the current one against WordPress.

You can’t just upload WordPress, perform a bunch of customizations, install 50 plugins, 50 themes, and think everything will be fine from that day forward. WordPress along with the associated technologies are always evolving. That means your site must evolve as well.

One of the commonalities between most of the comments I’ve read regarding the worm attack consisted of upgrades breaking themes or plugins. Based on experience, I have never experienced a problem with a plugin or a theme completely breaking my site thanks to an upgrade. Sure, I’ve had times where some of the theme or plugin functionality broke because of a deprecated function or changed behaviour, but that’s about it. Generally if an upgrade breaks a site, it’s because of a poorly coded plugin or theme. I can’t believe this attitude that functionality trumps security. There are hundreds of plugins within the repository, if you’re afraid of one breaking or feel that it is not compatible with the upgrade, deactivate it until an update for it is available or use a replacement. Missing a small portion of functionality is better than having your entire site compromised.

But I Didn’t Know

This is by far the lamest excuse I’ve ever heard. When a new version of WordPress is released, here are the following ways you can find out.

Log into your dashboard and look for a colored message in the top center of your screen which says something like WordPress X.X.X is available! Please Update Now. The link will take you to the one click auto ugprader.

Activate the WordPress Development Blog dashboard widget. This will show you the latest posts from the WordPress development blog. If there is a new update, there will be a new post saying so.

In the bottom right corner of the administration panel, there will be the text Get X.X.X. This is a link to the one click upgrader letting you know you’re running an out of date version.

Follow the WordPress blog account on Twitter. @wordpress this account is managed by the WordPress team and usually will contain links to blog posts regarding new releases.

Follow blogs that report on the happenings within the community. The WordPress community does a great job spreading the word when a new version is released.

WordPress does maintain an announcement mailing list that you can subscribe to by checking a box in your WordPress forum profile but in my opinion, they have done a terrible job utilizing that list.

The Decisions You Make Today Shape Your Tomorrow

One question you should ask yourself before installing any theme or plugin is whether or not it will prevent you from upgrading. The same holds true for custom development work. A theme or plugin that is custom developed which does things in such a way that makes upgrading a pain means they developed it wrong. For starters, no one should ever hack any of the core files. Secondly, developers should use hooks and existing APIs to achieve functionality. If the functionality does not exist, they should create a ticket in Trac and request that a particular hook or API be added to core so core edits do not take place.

WordPress Can’t Do It All

WordPress has made it incredibly simple to upgrade with the addition of the one click upgrader yet so many still don’t seem to upgrade in a timely fashion. I realize the auto upgrader does not work for everyone but there are alternatives. It’s getting to the point where it seems as though the only way to curb irresponsibility is automation of upgrades. However, I believe this would create more problems than solve. Since automation is not likely to occur, the responsibility falls back on you, the individual. Take that responsibility seriously.

Please upgrade your WordPress blog to the latest version ASAP. Our own PluginBlog was vulnerable and was compromised (shame on me for not having upgraded from a really old version). Our blog had registration turned off.

After upgrading your blog and changing your password to a strong one, you can visit Lorelle’s post to find more ways to secure your install and remove the extra admin account that might have been created as part of the attack.

I removed the extra administrator account through phpMyAdmin and it was the last account created. You could also find the last account created and if it does not look familiar, could delete it and see if the number of Administrators in the user control panel is reduced to the original amount you expect to see.