Is WordPress More Secure with a Changed Database Prefix?

Last updated on November 17th, 2014 by Robert Abela. Filed under WordPress Security

There are several WordPress hacks and tweaks you can apply to your WordPress to improve its security. One of the most popular tweaks is to change the default WordPress database prefix. You can change the WordPress database prefix manually or automatically with a WordPress security plugin. Whichever method you use makes no difference, although I recommend you to do it manually. If something goes wrong you can easily revert all the changes and troubleshoot any issue you might encounter.

Like with any other WordPress hack, some people are a bit sceptical about changing the WordPress database prefix. Does it really work? Is it worth implementing? In this WordPress security article I will explain just that; how does the changing of the WordPress database prefix improve the security of your WordPress and help you contain the exploitation of an SQL Injection vulnerability should your WordPress be vulnerable to it, especially in the case of automated mass WordPress attacks.

SQL Injection Vulnerability – Back to Basics

Let’s start by first briefly explaining what an SQL Injection is. In short an SQL Injection gives the attacker the ability to inject SQL code through an input accessible by visitors (both visible or not) and have it executed by the database server, in WordPress’ case the MySQL server where the WordPress database is hosted. For example imagine that instead of entering an email address in a sign up form, the attacker enters SQL code which lists all the entries in the wp_users table, where the credentials of all WordPress users are stored.

Therefore once the form is submitted, instead of rejecting the SQL code, the website executes it and the database server returns the content of wp_users table to the attacker. SQL Injection, i.e. the execution of code through a website input is typically the result of a problem in the code of a form, plugin, theme or some other component that could be used on a WordPress website. It mainly happens because the user’s input is not being sanitized, hence is allowed to enter content such as SQL code.

That is it basically. In a typical WordPress installation the attacker can also write to the database, which is even more dangerous as we will see further below in this article. Like anything else there are several other variants of SQL Injections, some of which can be quite advanced but this should give you a good overview of how an SQL Injection vulnerability can be exploited and what impact it can have once exploited, i.e. the attacker can virtually retrieve any data he wants from your WordPress database and also write to it. For more information on SQL Injections you can refer to the SQL Injection article on Wikipedia.

Now let’s see how it all works in a WordPress installation and also see how the changing of the default WordPress database prefix helps in mitigating such type of malicious WordPress hack attacks.

WordPress Database Tables and Names

When you install WordPress it creates 11 tables in the MySQL database, all of which have the same prefix by default; wp_. Therefore unless the database table prefixes have been changed, there are for sure the following tables in a WordPress database:

  • wp_commentmeta
  • wp_comments
  • wp_links
  • wp_options
  • wp_postmeta
  • wp_posts
  • wp_terms
  • wp_term_relationships
  • wp_term_taxonomy
  • wp_usermeta
  • wp_users

Just by reading the tables’ names you can easily determine what each table is used for. For example the wp_posts is where all the blog post, pages and custom post type text is stored. The wp_options table is where all the WordPress options are stored, and where several plugins store their settings. The most interesting table is the wp_users, where the WordPress usernames and their MD5 hashed passwords are stored.

Exploiting an SQL Injection on WordPress

Let’s assume that one of the plugins you have installed on your WordPress is vulnerable to a known SQL Injection vulnerability which is being widely exploiting in a mass WordPress attack. Typically the attackers start by automatically scanning a wide variety of website with tools such as WPScan to identify which of them are vulnerable. In this case your website is flagged as vulnerable therefore the attack continues being executed against your website and the next stage is to exploit the SQL Injection and execute the SQL code below, which is used to manually create a WordPress administrator in the WordPress database.

INSERT INTO `wordpressdatabase`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_status`, `display_name`) VALUES ('1000', 'tempuser', MD5('Str0ngPa55!'), 'tempuser', 'support@wpwhitesecurity.com', '0', 'Temp User');
INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_user_level', '10');

What does the above mean? It means that the automated WordPress attack was able to create a WordPress user with administrator privileges on your WordPress blog or website, thus the attackers automatically gain access to your WordPress admin pages, i.e. the dashboard. Alternatively rather than going through all the hassle of creating a new WordPress username the attackers could have also changed the password of the existing administrator account but that would lock someone out, hence prompting suspicion.

How Was the Attacker Able to Create a WordPress Administrator?

Knowing that the target website is running on WordPress and that is vulnerable to SQL injection, the attacker only needed to have some basic knowledge of the WordPress database setup (which is freely available) to craft the automated attack.

Guessing WordPress Database Table Names

Since the WordPress database prefix of the target website was the default one, i.e. wp_ the automated attack could easily execute code and read or write information to such tables. If the WordPress database prefix was changed to something else, for example W9Pr3_ then the automated attack would have not been able to read or write to the WordPress database.

Typically these types of attacks are crafted to exploit WordPress installations using the default prefixes. Yes there are ways and means how to craft an attack that could try to guess the WordPress database prefix though such type of attacks consume a lot of resources and take much longer to execute hence the chances of being identified are much higher. Also most WordPress users unfortunately still use the default WordPress database prefix so there is still a lot to exploit out there, hence it is not worth the hassle and complicate the attack when there is still such a big target. So as we have just learnt, even if the SQL Injection is exploitable as such the hacker’s malicious intents are contained.

Changing WordPress Database Prefix Improves the Security of WordPress

The idea of changing the WordPress database table prefix originated in the early days of WordPress, when a worm was automatically exploiting an SQL Injection and automatically creating a user on the target WordPress websites and blogs, thus gaining access to them to be able to inject malware and spam. The only way to stop it was to change the WordPress default table names. As usual there have been some unique attacks which circumvented the changed WordPress database prefix hack and were still able to access the WordPress database, but these were just the one offs.

Not a Bullet Proof WordPress Security Solution

Therefore changing the WordPress database prefix is not a bullet proof solution, like all of the other security solutions. Though it does work in 99.9% of the cases which in the WordPress’ ecosystem are automated attacks. Hence it is worth implementing. Of course it is worth mentioning that keeping a WordPress audit log to monitor all activity on WordPress with a plugin such as WP Security Audit Log always helps in such situations. WP Security Audit Log plugin also has an email notifications extension that you can configure to alert you via email each time a new user is created on your WordPress, or a WordPress user profile is modified and much more. Definitely worth a try.

Last but not least, as we always say it is also very important to keep your WordPress and WordPress plugins and themes up to date and ensure all WordPress users use strong passwords.

WordPress Hosting, Firewall and Backup

This Website is:

3 comments

Eric 23/10/2014

Great post! Such a simple step can really help secure a site.

Mickey 25/10/2014

Question – couldn’t the injection attack just check for all existing tables, regardless of prefix, and then use some basic string matching to identify specific tables (eg whateverprefix_users) and perform the same attack?

Robert Abela 25/10/2014

Hi Mickey,

Good question. As explained there are ways and means how scripts can automatically guess the tables’ name, even when they have a non default prefix though it requires a lot of effort and resources hence for attackers it is not worth doing considering there are many other easier targets.

Leave a Reply

Your email address will not be published. Required fields are marked *