Three WordPress Security Mistakes You Didn’t Realize You Made

Considering the amount of malicious activity that takes place on the internet, it’s no surprise that successful attacks on WordPress sites are launched across a wide variety of vectors. Whether outdated plugin code is to blame, or password reuse, or any number of other security flaws, no site owner sets out to introduce a vulnerability into their environment. Ultimately any security issue begins with a mistake, and while mistakes are forgivable there’s still risk involved if they’re not discovered and remedied.

In today’s post, we’ll look at a few common mistakes made by owners of WordPress sites that can create security concerns. These mistakes aren’t strictly application-specific, but are issues many WordPress users will encounter in the course of running their site.

 

Mistake 1 – Abusing Addon Domains

In the era of one-stop-shop customer experiences, it can be attractive for a WordPress design agency to be able to offer site hosting to their clients. However, when corners are cut in the implementation of such solutions, security flaws begin to surface.

Web hosts commonly make use of user-friendly control panels, like cPanel and Plesk, to improve the process of handling many server-side tasks for typical websites. Common operations like FTP user management and database setup can be done easily by just about anyone through a handy web interface. Many hosting companies running such control panels also allow their users to create and host multiple domains within a single account. In cPanel and most other contexts, these are called addon domains. With addon domains, a user can easily start and manage a number of sites without investing in separate hosting accounts for each of them. Many shared hosting providers encourage this use of addon domains, offering plans which allow users to run “unlimited” sites on a single account. However, misusing addon domains can create an insecure condition in the event that multiple users have access to the account–authorized or otherwise.

When a script on a webserver is accessed by a client, like a visitor requesting WordPress’s index.php file, the process is executed by a certain user account on the server itself. On typical WHM/cPanel servers, web processes are run as the user associated with the site’s cPanel account. Put another way, if I have a cPanel account with the username mikeyv and host three WordPress sites on it, every PHP process for each site executes as mikeyv on the server itself. This means that scripts running on one site have the ability to read and write files on other sites within the same cPanel account. Consequently, if those three WordPress sites each belong to a different one of my clients, it becomes possible for someone with file access to any one of the sites to influence the rest.

What’s The Problem?

There are two primary causes for concern with this particular mistake. First, in general this means that a disgruntled or otherwise troublemaking contributor to one of your addon domains can be disruptive (or worse) to other sites in your account. As long as they have FTP access or administrative permissions to their site, they can cause considerable damage to your account if they’re of a mind to. Even in cases where an FTP account associated with one of the addon domains may be jailed to its own site’s directory, if the user is able to upload a PHP file they can traverse the entirety of the cPanel account with a web shell or similar script.

The second cause for concern is in the case of a security incident. If one site is vulnerable and an attacker installs a backdoor, they now have complete access to further infect the rest of the sites you’re hosting. This scenario is a common one, and often results in cases of repeated reinfection. When the owner of the cPanel account is unaware of the scope of the infection, it’s common for the individual infected sites to be restored by their respective owners, allowing them to be immediately reinfected by scripts contained elsewhere in the account.

What Should I Do?

If you don’t host multiple sites within the same hosting account, you’re in the clear. If you do host multiple sites in one account, but you and other administrators are approved to access them all, just remain aware that any security issue for one site is an issue for all of them.

However, if you host multiple sites in the same account that belong to different clients, or each have different administrators, it should become a priority to get these sites isolated as soon as possible. While there are costs associated with maintaining hosting accounts for each client, it simply isn’t worth the risk to your business if an incident were to occur.

Mistake 2 – Unsafe Copying & Renaming

It’s always a good idea to make a backup of an important file if you’re making a risky change to it. After all, it’s already bad enough that something is getting tweaked on the live site, so you’d better make sure you can revert the change quickly in case it doesn’t behave as intended. The tricky part here is that depending on how you’re making the backup copy of that file, you could be exposing sensitive information about your site.

It’s fairly common to see these hastily-made copies of files given names ending in something like .bak or .old. For example, if someone is making a quick change to their site’s wp-config.php file, they might make a copy first and name it wp-config.php.bak. That way, later on they can easily identify the contents and purpose of the file in case they need to restore it.

What’s The Problem?

The issue here stems from the way your web server treats files based on their extensions. While there’s nothing inherently “magic” about file extensions like .php and .jpg, applications will typically use the extension as a way to interpret how a file should be handled. In particular, a web server is going to see a request to a file ending in “.php” and assume it contains PHP code to be processed locally. Once processed, the response sent to the client contains the output of the script, but not the code itself.

When a file is instead given an unknown extension like .bak, the server will need to fall back on default behavior in determining what to do if the file is requested by a client. In most cases, the default behavior will be to treat it as a download and simply send the requested file as-is to the client. This means if an attacker successfully guesses that our example site contains a file named wp-config.php.bak, they can download that file and read its contents, giving them access to database credentials and cryptographic salts.

Additionally, unsafe directory backup practices can allow highly vulnerable code to remain accessible on your site long after it would have been removed otherwise. For example, if you redesigned your site and left the old one in a subdirectory like /oldsite or /backup for some reason or another, those directories will still be accessible on the web. Any vulnerable code present in the defunct sites may still allow an attacker to breach your environment and infect your primary site.

What Should I Do?

Short answer, don’t leave files hanging around your WordPress environment when you no longer need them. In the cases where you must, though, just be sure to keep a file’s original extension at the end of the renamed file. To call back our example above, wp-config_backup.php is still a perfectly descriptive name which has the advantage of not being freely downloadable to anyone on the internet.

For the sake of completeness, yes, it’s possible to hack in some special handling for your .bak files into your site’s .htaccess or webserver configuration. With that said, it’s far outside the scope of this article, and still probably a better idea just not to use the unsafe extension to begin with.

Mistake 3 – Hosting Email On Your Webserver

The initial shopping stage of building a web presence can be tough. Eventually though, you nabbed a good deal for a hosting plan and–Score!–it came with unlimited free email accounts! You knew there were professional email solutions around, but you seriously can’t beat free.

Fast forward a bit, and now you’ve got a site pulling in a respectable amount of traffic, and a dozen or more inboxes belonging to members of your team. They use their email to talk to each other, send documents to clients, and receive any number of automated emails from various services.

What’s The Problem?

As we discussed in Mistake 1 above, all of the files in a cPanel account are owned by the same user. This user also happens to pass on its authority to any PHP scripts it executes. What many fail to realize is that the email inboxes within your cPanel account are all still just files living under that very same account ownership.

The practical implication of this situation is similar to the above. Any user with filesystem access on the account (whether it’s a legitimate FTP user, or a WordPress administrator, or a malicious intruder) can access the directory structure that contains all of the cPanel account’s mailboxes.

While the immediate privacy concerns of someone reading someone else’s email are obvious, the problem compounds when third-party services are considered. Effectively, this means that an attacker is able to perform password resets for accounts associated with the cPanel-hosted email addresses, since they can copy the email validation links out of the raw email file directly. This technique can allow the attacker to pivot from a web application breach to much larger scopes, depending on the kind of accounts associated with affected email addresses. Is your company Twitter account associated with one of these addresses? How about financial accounts?

What Should I Do?

If the email for your domain is hosted on a cPanel account (or any similar environment, as this isn’t necessarily a cPanel-specific problem), consider your use case carefully. If you’re running a hobby blog and just need a simple info@example.com address, you’re probably okay as long as you’re aware of the risks. If you’re running a business of any notable size, though, it’s highly recommended that you seek out a standalone email solution in order to isolate mail from your webserver entirely.

Note that these warnings apply to typical shared environments, and individual systems may be configured more or less securely. Through use of open_basedir and disable_functions restrictions to prevent PHP from reading files outside of allowed directories or from executing system calls, it can be made more difficult for an attacker to access email hosted on the account. However, these measures are far from bulletproof and there are documented methods to bypass such restrictions. In general, it’s still a safer decision just to get the mailboxes onto a different environment.

Conclusion

Whether it’s the result of a hasty shortcut or honest inexperience, mistakes are bound to happen and don’t have to be the end of the world. Just be sure to remain mindful of the decisions you make in the process of running your website. Don’t cram a bunch of clients into the same hosting account, don’t leave sensitive files accessible to the web, and don’t keep your email where someone else could read it. Thanks for reading!