The Top 10 WordPress Security Mistakes

Sooner or later, we all deploy a PHP web application (Joomla, WordPress, Magento, etc.). I’m currently doing some security work, and I deal with a huge number of sites that have been hacked. The crazy thing is that 90+ percent of these compromises could have been prevented by a few security precautions. Here’s a list of the most common misconfigurations and security holes (from a System Administrator’s perspective), along with how to fix them.

We also look at some of the most popular goals of the attackers (‘consequences’).

 

1. Web Application missing Updates

The most common security problem, hands down, is unpatched or known-vulnerable software. This is usually in the form of outdated or insecure plugins, although it’s also often an outdated version of the Web Application (I regularly see Joomla 1.5 sites, which were current about 10 years ago). Again, this accounts for more than half of the compromises I see every day. The easiest way to fix this is to turn automatic updates on. Because auto-updates of major versions often break plugins and themes, this is often not configured.

In WordPress, for example, you can work around this by enabling updates of minor versions only. Here’s the code for your ./wp-config.php file:

define( 'WP_AUTO_UPDATE_CORE', true );     // updates major, minor, and development versions

define( 'WP_AUTO_UPDATE_CORE', 'minor' );  // updates minor versions only -- less likely to break themes + plugins

 

1b. Vulnerable Plugins

The great thing about Content Management Systems (CMS) like WordPress is that they give you access to a huge amount of functionality through free and paid plugins. The problem is that each plugin you run is a potential vulnerability. The more plugins you have, the better your chances of unknowingly having a security hole on your site. So: the less plugins you run, the better.

Older and more popular plugins tend to have much better code review and support, which makes your chances slightly better.

 

2. Incorrect File or Directory Permissions

First time system administrators often mix up their “testing the process” with “deploying the application.” Many don’t have test or staging environments, and are just trying to get Grandma’s Blog to run. “I’ll fix this configuration stuff later,” they tell themselves. Obviously, “later” never comes and the application is deployed with incorrect/insecure file permissions.

To review:

• Files should have a permission of 644 (owner read/write, group and other read).

• Directories should have permissions set to 755 (owner everything, group and other read/execute).

• Ownership: you’ll generally want site files to be owned by a specific site user (so you can have SSH/sFTP login for that user only), with group ownership for the web server process. You do not want the web server process to have ‘write’ permissions for your site. There are exceptions to this sometimes (‘upload’ directories where web users can upload files, for example).

 

Shortcuts for this:

cd $PATH_TO_SITE                        # go to your siteroot; the base directory for your website

find . -type d -exec chmod 755 {} \;    # find all subdirectories and change their permissions to 755

find . -type f -exec chmod 644 {} \;    # find all files in subdirectories and change their permissions to 644

Then you can change ownership for your files like this (substitute valid username, web process name (www or www-data, usually), and the path to your website in place of the shell variables here):

chown -R $SITEUSER:$WEB_SERVER_USER $PATH_TO_SITE

 

3. Many Websites sharing the same PHP Process

Unfortunately this is the default for 99% of hosting companies. Although users are usually isolated from each other, each user only gets a single PHP process to be shared by all their sites. You can think of it like this:

The server (or user account on the server) is like your house. Each website is like a window. If one of your websites has a vulnerability, the bad guys will simply come in through that site, and all your other sites sharing the same PHP process — regardless of whether they have vulnerabilities or not — are toast.

 

4. Your Web User has a Shell

If you run the following command (looking for the user details for the web user):

grep www /etc/passwd

…and you see that the user has a shell like ‘/usr/sbin/nologin’ or ‘/bin/false’, this is a Good Thing. If you see a real shell, like /bin/bash or /bin/sh, this is BAAAAD. You do not want your web server process to have access to a shell, in case someone manages to gain control over it.

 

5. Insecure Passwords (or using Passwords at all, instead of Keys)

Many people still use FTP, a protocol that is older than I am. sFTP (the same thing, but with an encrypted connection) is better. SSH is fine as long as you use key-based login, if you need to give users a shell on your system for some reason.

Make sure you have strong passwords on your

• hosting control panel,

• DNS/registrar account (if different from your hosting company)

• sFTP, if you’re using it

 

If you use SSH, here’s how to set it up for higher-than-default security (these settings are default on the the BSDs, but not on most Linux distributions):

• No root login from the Internet. Use ‘sudo’ for becoming root.
• No password-based logins. Use cryptographic keys instead.

 

6. Other Threats

This started as a list with 10 items, I swear! Check the first video I embedded to confirm this. In the Blog-Post-version, I’ve condensed some of these threats/risks and shifted them around, so now there only seem to be 6. Here’s a rundown of other things that frequently ruin the fun:

 

• badly engineered plugins/themes/etc.
• vulnerable ‘custom’ code — uploaders with no authentication, etc.
• malvertising (third-rate advertising networks that frequently allow people to sneak malware into their ads).

 

Consequences

If you’re wondering what the bad guys actually want with most sites, the answers are fairly simple. Most websites that are compromised have a few things happen:

1. Search-Engine Optimization (SEO) Silliness. Bad guys often want to improve the search rankings of other sites (either for money or to drive more traffic to other infected sites). This takes the form of injecting content into the site (hidden links), adding content that they want search engines to index (posts and pages not linked to from the rest of the site), and promoting the infected site on other infected sites.
2. E-Mail Spam. Yeah, most of that stuff you get in your spam folder is from hacked sites. If the PHP process for your site is allowed to send mail, attackers will usually just start filling the mail queue with tens of thousands of spam e-mails.
3. Redirects — redirecting some (or all) users to other sites, for whatever reason — to display ads, attack the users’ browser, etc.
4. Attacks on visitors: usually through client-side Javascript code, attackers will attack visitors’ browsers if they fit the profile of older, more vulnerable versions.
5. Attacks on other websites, in the form of denial-of-service (DOS) attacks, SSH and FTP login attempts, etc.
6. Attempting to take over the server. This is more rare, but some attackers try to break out of their little website’s environment to take over the whole server.

There are lots more evil things that attackers do on the websites they compromise, but those are some extremely popular choices.

Almost all of them result in your site being blacklisted on the major Web and e-mail blacklists, having your legitimate search rankings torpedoed, having search engines and browsers display warnings about your site in the search results, insane amounts of web traffic from other infected sites linking to fraudulent content on your site, and other horrific stuff.