The WordPress Evangelist

Some of my blogs were recently hacked into, so I decided to implement this particular security measure that I’d long heard of but never really bothered to get around doing. The hacking attempts are what’s termed as zero-day SQL injection attacks. Basically, two things happened:

• In several blogs of mine, users with admin access were inserted without my knowledge.
• In one blog, a number of my latest posts were deleted at the application level (not the database level) — meaning, the posts were erased manually, presumably because they were able to gain access to my dashboard with admin rights. (Good thing WP has a recycle bin!)

What I did was to change all my database tables’ prefix from wp_ to something else (for our purposes, let’s use “somethingelse_“). According to some WordPress plugin developers, having your database tables named with a prefix other than wp_ increases your site’s security by preventing malicious insertions. Simply put, hackers out there know that WordPress db tables are prefixed by “wp_” by default, so that it’s fairly easy for them to create scripts that can wreak havoc in your database.

So then, this is what I did for all my blogs. I renamed all my databases’ tables (wp_options, wp_users, wp_posts, etc.) so that they would all have a new prefix. I even went as far as using a different prefix for each database. Then, so that WordPress would know what the new prefix was, I redeclared it in wp-config.php. Like so:

<?php
/**
 * 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  = 'somethingelse_';
?>

I made a rather serious mistake, though. What I actually did was to download the database from phpMyAdmin (using the prescribed db backup procedure) and modify the downloaded .sql file. I used a text editor to rename all references to wp_ to somethingelse_. Then, I dropped the tables from the database and inserted new ones using the modified backup. Problem was, I also inadvertently renamed some database meta keys in the somethingelse_postmeta table, which caused some rather alarming changes to my blogs. For example, the meta keys _wp_attachment_file and _wp_attachment_metadata were also renamed to “_somethingelse_attachment_file” and “_somethingelse_attachment_metadata”. That caused all my images to lose their meta information and resulted in WordPress not knowing which thumbnails were associated with which images anymore! Solution: I renamed all instances of _somethingelse_ back to “_wp_” in the somethingelse_postmeta table.

Something else happened that confirmed to me that the hacking was a zero-day SQL injection attack. Just when I completed the renaming of my database tables for all my WordPress installations, one of the databases suddenly acquired a new set of tables!! There they were, new tables prefixed by wp_ alongside the real db tables. The wp_users table contained an admin user with a bogus email address — imagine what those hackers could’ve done to my blog if I hadn’t implemented this security measure. How my databases were intruded upon, however, still remains a mystery as of press time…

N.B.: While you should be aware that the meta keys in the somethingelse_postmeta table should remain with their _wp_ prefixes, the meta keys in the somethingelse_usermeta table should be prefixed by whatever new prefix name you’ve chosen. And, there is an entry in the somethingelse_options table that’s originally called wp_user_roles. If you do change your table prefix to something else, make sure that that entry is also renamed to somethingelse_user_roles.

The process is quite involved, I know. But this security measure is urgently recommended if you mean to keep your WordPress installation(s) safe from hacking attempts.