Security should be one of your fore-most concerns with any website, and this eBook is free and available in PDF, EPUB, and Kindle formats, so get it while it’s hot!

WordPress 3.4 Beta 3 is still not ready for prime time, but provides almost 90 fixes since the second beta release. Please do take a few swings at it on a test installation, especially if you are a plugin or theme developer. If you find any bugs, please report them, and contact the support forums if you need any help.

If you’re currently running on the WordPress 3.3 branch, please update to 3.3.2 as soon as you can!

If you can’t make it, don’t worry. iThemes will be providing a recording later for viewing at your leisure.

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.