5 Steps to Guarantee Your WordPress site will be Hacked. Soon.

August 13, 2012   ·   By   ·   7 Comments   ·   Posted in Security, Wordpress

It was pointed out to me recently that we’ve been pretty discriminatory here on the blog recently, assuming that people want to avoid getting hacked. What about the people who *want* to be hacked? Maybe you’re interested in hearing about the political leanings of web savvy (and morally undeveloped) youth. Maybe you enjoy the thrill of the chase in figuring out how a hacker got in. Maybe you’re just lazy. Whatever the case, here are 5 steps you can take today (or just not worry about fixing) to put yourself at risk:

  1. Don’t Worry About Updates

    After all, updates can break your site, right? Just ignore them. Plugin updates, theme updates, core updates. Heck – even updates to your FTP client or operating system – they can all wait.

  2. Install Plugins and Themes from Anywhere

    This theme has encrypted code in the footer to prevent the author’s “Real Estate Miami” link from being removed? That’s a sign of professionalism and quality. Use it.

  3. Use Weak Usernames/Passwords

    No one is going to guess that your password is “Password”. Maybe “123456″ is just the password you always use so you can remember it. What are the odds that somebody is going to check your little corner of the web and try the password?

  4. Host all 97 of your sites as addon domains

    Reseller hosting is for suckers, and anything more than $10/month for hosting is highway robbery. Having all of your sites accessible via one FTP login is so convenient it’s worth the risk.

  5. Don’t worry about backups.

    Logically, this won’t make you less secure. But according to logic, the toast you drop in the morning should land butter side up 50% of the time. We all know it’s butter down every. Single. Time. Somehow, a site without backups is just more likely to get hacked.

Yes, this is all terrible advice. Over the next week or so, we’ll be putting out a post on each one of these topics – why they’re a problem, and what you can do to solve them – so check back! In the meantime, I’d love to hear more tips on how people (inadvertently) make their sites less secure – share in the comments!

How to Change Your WordPress Table Prefix

August 3, 2011   ·   By   ·   14 Comments   ·   Posted in Security, Wordpress

Lately, WordPress users seem to have had an increased interest in security – and with good reasons. Yesterday’s timthumb.php vulnerability, plus a slew of others in the past few months have really put most site owners on edge.

Often it’s recommended that as a WordPress site owner, you change your WordPress database table prefix to something other than wp_. It’s not a bad idea – in certain situations, doing so might prevent a hacker from gaining more access to your site, or limit his destructive capability, and it’s a very easy thing to change.

If You’re Installing WordPress

If you’re installing WordPress, and you havent run through the install process, changing your table prefix is incredibly simple. During the install process, just set the Table Prefix to anything you’d like:

If You’ve Already Installed WordPress

If you’ve already installed WordPress, you can still change your table prefix, but it’s a little more complicated. You’re going to need to have access to your database through PHPMyAdmin or a similar system.

  1. First, open your wp-config.php file (You’ll need to download this via FTP, or get at it from your host’s file manager). This file is usually located in the web root of your site.
  2. Now, scan down until you see a line that starts with ‘$table_prefix’. It will look something like this:
     * 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_';

    Change the value between the quotes (after the = sign) to whatever you’d like:

     * 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  = 'mysecretprefix_';
  3. Upload the file to your site, replacing the old wp-config.php file (If you made these changes from the built in file editor for your host – like cPanel, you just need to click the “save” button).

    At this point, your site will totally stop working. Yikes! Fortunately, we can fix that by changing some things in the database (Remember how you were supposed to make sure you had database access before we started? If you don’t, change wp_config.php back to the way it was, quick!).

  4. Fire up PHPMyAdmin (or the MySQL client of your choice), and connect to the database for this WordPress install.
  5. Run through each table starting with wp, and rename it, as follows:
    1. Click on the table name in the left sidebar
    2. Click on the “Operations” tab
    3. Change “wp_” to “mysecretprefix_” in the upper right field
    4. Repeat for each table
    5. At this point, your site should be working properly again, with one important caveat: You get a permissions error when you try to log in. That leads us to our last set of steps:

      Choose the mysecretprefix_usermeta table, and look for a row with a user_id of 1 (or whatever your user’s id is – it’s probably 1), and a “meta_key” value of “wp_capabilities”. Once you’ve found this. Click the pencil toward the left (edit)

    6. Replace the wp_ in the meta_key row to “mysecretprefix_”
    7. You need to make this same change to 2 more records – wp_user_level (located in wp_usermeta – again, make sure you’re changing it for the right user), and wp_user_roles, which is in the mysecretprefix_options table. Both of them should have wp_ replaced with mysecretprefix_.
    8. All done!

    If You’re Installing WordPress, and You’re Not Interested in all that Hassle:

    This one probably should have gone first: The plugin WP Security Scan from WebsiteDefender will do all the dirty work for you in most cases. Just go to the “Database” page, and switch your prefix.

How to Clean Up the TimThumb Security Vulnerability

August 2, 2011   ·   By   ·   18 Comments   ·   Posted in Security

Yesterday, Mark Maunder over at managed to track down the source of a pretty clever hack on his site, where the hacker gained access through the massively popular TimThumb image thumbnail creation library. You can read his full post on the matter here:
Zero Day Vulnerability in Many WordPress Themes
He’s made an interesting post detailing the work he did to catch the hack – If you have the time, give it a read.

More importantly – this hack has the potential to affect hundreds of thousands of WordPress installs. Unfortunately, because the timthumb library is generally included in themes (both free and premium), it’s not going to be very easy to get patched. Premium theme sellers will no doubt release updates and notify their users, but free theme users are less likely to have such good luck. As such, it’s going to be a good idea to check your site out for this vulnerability, and fix it as soon as possible.

(Note – Subscribers to Locker have had their sites scanned for this vulnerability, and are being automatically notified if they’ve got a problem right now.)

How do I know if I’m vulnerable?

Nearly anyone using the timthumb library, who downloaded it before yesterday (8/1/11) is likely to be vulnerable. How do you know if you’re using timthumb? The easiest way is probably to check out your theme folders for a file called timthumb.php, using FTP, or your host’s file browser. If you’re using a host with cPanel (like Hostgator), it’s very easy – just load up the file manager, and then use the “Find” box in the upper right corner to search for timthumb.php. No results? Chances are good that you’re safe.

Make sure you check every folder in your theme – it’s likely that if your theme has a lot of included files, this file would be in a directory inside your main theme folder.

Ok, the file is there – now what?

Fortunately, thanks to the hard work of Mark in finding this and bringing it to light, Ben (the creator of TimThumb), and a few other folks, there is a more secure version of the script now available for download here:
To secure your site, save that file (File->Save Page As in most browsers) to your computer, and then upload it to your site via FTP, replacing every instance of timthumb.php with the new version you just downloaded. If that’s beyond you, or you want to be absolutely sure that you’ve closed the hole up, send me an email at, or hit me on twitter @peterbutler, and I’ll help get you straightened out.

Good luck!