WordPress Security

[jason]

Hello fellow WordPress users. I'm Jason, a long-time JPC customer (10+ years, I believe). Until I took a new job a couple years ago, I was a fixture on these forums, but lately I don't have the time to continuously check in and I've kind of fallen out of touch.

Well, there's nothing like a catastrophic server failure to bring you back...it figures that the server that's down hosts the two sites I wanted to work on today. So, while I was checking in for an update on newscion, I figured I'd poke around a bit to see what else is going on.

I noticed Katrina's WordPress security advisory post from November and wanted to add something that I came across. I should mention that my new job involves managing the web hosting for a mid-sized western New York state university. We host a lot of CMS-based sites that are often set up by student employees for a departments that, once the students leaves the job, stop doing software updates and eventually get compromised. WordPress seems to be out biggest offender.

During a rash of pharmacutical ad injections over the summer, one of our information security investigator's found some research from Utah State University on issues they were having with WordPress. The paper is pretty technical, but the jist of it is this:

• WordPress uses a series of "random" keys for security purposes.
• You can set these keys yourself in wp-config.php but, if you don't, WordPress should randomly generate them at runtime.
• Unfortunately this random generation is not done because the default wp-config file has default text that WordPress thinks is the user-generated keys.
• Knowing that many sites do not change this default text, hackers can forge authentication tokens on these sites and obtain administrative access with little difficulty.

After reading that paper, I began reviewing the sites that had been compromised on our servers. Not all, but most, of the sites were running WordPress. Of those that were using WordPress, EVERY SINGLE ONE HAD THE DEFAULT TEXT.

If you download and install WordPress without first creating a custom wp-config file, WordPress will try to create one for you. If its successful, the keys and salts will be set correctly. If you follow the standard instructions on wordpress.org, however, it will have you create a custom wp-config file first. While the instructions do say to set the keys, this step is rather understated and easy to overlook.

If you are running WordPress, take a minute to check your wp-config.php file. About midway down the file you should see a bunch of lines where the keys are set (example below). If you see the text "put your unique phrase here" on those lines, your site is vulnerable. Replace the "put your unique phrase here" text with random text like "FVxL30?d+67WiAPUUQ4xR&k1&-4~/3Lwfh;7m78Ri~4bE0%Vi6/V{q+YqV3Pgn>Y" (the longer the better and don't use my string exactly, either).

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ 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');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

/**#@-*/ 

WordPress has a tool that will create the values for you, too: https://api.wordpress.org/secret-key/1.1/salt/

Also, if you've been running WordPress for a very long time and have never updated your wp-settings file (as was the case with my personal blog, btw), you might want to take a look at the current sample file and update yours. A lot has changed in that file over the years. In my case, the file didn't have the keys defined at all. This should mean that WordPress was creating them randomly (since there were no defaults set), but just to be safe, I added my own settings anyway.

Good luck and happy (secure) blogging!

--Jason

[gohighvoltage]

HI Jason, Welcome back bud!

Great Information!!! I went and checked my Keys and they were all good, but It is great to know to look out for that! Much Appreciated!

[Vin DSL]

Man! That section wasn't even included in my wp-config.php file - and I auto-update WP all the time.

I didn't have an example of how the entire file was supposed to look, soooo...

I ran around the web, until I discovered one in the clear (someone forgot the closing php tag) LoL!

Mine didn't look anything like the one I found -- probably half of it was missing! My entire file was 23 lines.

Anyway, good to hear from you again, jason!

I've been thinking about you lately - wondering if you were still hosted here.

Thanks, for the heads-up!!!

[Vin DSL]

BTW, AFAIK, this is how a proper wp-config,php should look...

<?php
/**
 * The base configurations of the WordPress.
 *
 * This file has the following configurations: MySQL settings, Table Prefix,
 * Secret Keys, WordPress Language, and ABSPATH. You can find more information
 * by visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing
 * wp-config.php} Codex page. You can get the MySQL settings from your web host.
 *
 * This file is used by the wp-config.php creation script during the
 * installation. You don't have to use the web site, you can just copy this file
 * to "wp-config.php" and fill in the values.
 *
 * @package WordPress
 */

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'hey_bud_1');

/** MySQL database username */
define('DB_USER', 'hey_bud_2');

/** MySQL database password */
define('DB_PASSWORD', 'password_goes_here_bud');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ 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 bud');
define('SECURE_AUTH_KEY',  'put your unique phrase here bud');
define('LOGGED_IN_KEY',    'put your unique phrase here bud');
define('NONCE_KEY',        'put your unique phrase here bud');
define('AUTH_SALT',        'put your unique phrase here bud');
define('SECURE_AUTH_SALT', 'put your unique phrase here bud');
define('LOGGED_IN_SALT',   'put your unique phrase here bud');
define('NONCE_SALT',       'put your unique phrase here bud');

/**#@-*/

/**
 * 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_';

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define ('WPLANG', '');

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
?>

[jason]

Man! That section wasn't even included in my wp-config.php file - and I auto-update WP all the time.

Yep...that's how mine was too. The updates don't touch the config file at all.

Since the key values aren't set in the older files they should be autogenerated, so you were probably pretty safe. Its just when an easy to guess value is preset in the file that it becomes a real issue.

I didn't have an example of how the entire file was supposed to look, soooo...

I ran around the web, until I discovered one in the clear (someone forgot the closing php tag) LoL!

I had to download a current version and look at the sample file that comes with it...but your way works, too, I guess. (As long as you didn't find it on one of my servers. )

Anyway, good to hear from you again, jason!

I've been thinking about you lately - wondering if you were still hosted here.

Still here...I rarely freelance anymore, but I've still got a bunch of sites here. I've missed everyone--even you, Vin!

--Jason

[Vin DSL]

Well, in my defense...

I started running WP in 2005. The first release was in 2003.

Linkage: WordPress › WordPress Now Available

So, it's likely that the config file was a little stale.

Looks like they finally got it right, though...

[Ron]

Mine is the old style too.

Methinks the wp code should be checking for the default key on admin login and warn (at a minimum).

Hey Jason, nice to see you around. Hope all is well.

[Vin DSL]

BTW, I already had some rudimentary regex in my .htaccess file(s), but this guy has taken it to a whole new level:

Linkage: WordPress › BulletProof Security « WordPress Plugins

I installed this plugin, while I was thinking about it. Highly recommended!