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!

 

Did you enjoy this post? Share it!

Comments

20 Comments
  • Mark, for issue #3, you said "or any similar environment, as this isn’t necessarily a cPanel-specific problem."

    Wanted to point out, in the Plesk control panel, which I believe is the #2 web hosting panel in terms of market share, the domain user accounts don't own email files for the same domain on the server. The files are owned by the mail system user account, with read/write/execute privileges limited to the mail system account (and root), i.e., not readable by rogue PHP scripts in the domain.

    Assuming the folks running the server know what they're doing, it's safe to host email and web for a domain on the same server.

  • Thank you for this post! Good info as always.
    Another good option for point 2 is setting strict file permissions. (ex. chmod 600 .htaccess.bak) Like you said, it's best to just delete those types of backups and maybe start using a VCS like git to track changes.

  • Thanks for the great informational post! Will pass along to my clients as well. Sometimes, we can all miss the fine details.

  • In response to David's comment regarding chmod 600. That actually wouldn't be a valid method. GENERALLY the file is owned by the daemon that's running it. So if the daemon is running as www-data and the file is owned by www-data, and you chmod 600 it, it's still readable by the daemon, thus it can still be viewed.

    To add to #2 though... I see people leave SQL dumps with names like backup.sql, dump,sql, etc. I would say getting into the habit of deleting these files, or at the very least removing them from a public facing directory, would be the best option overall, and the best habit to get into.

  • I really agree with the reported metrics and also advise by experience as a server, is to raise the security level for password generation, not to allow passwords of 30% level and only allow 70% of criteria already on servers.

    removal of necessary files:
    license.txt
    readme.html
    wp-config-sample.php

    Folder lock / download and use
    usually cloudlinux has no intrusion problems or if the server has enough tools for analysis like we use: inmunify360 followed by spf + MailScanner, Exploit Scanner, Anti-Malware and FTP Scans.

    The important cdn to tunnel and Nginx proxy then we see that a simple wordpress even unprotected from secure customizations are really strong!

  • As a novice wordpress hoster I appreciate the security articles that Wordpress put out. Sometimes it provides me with new information and sometimes it confirms what I have already done (always good to know). This one brought out new information for me that will have me rethinking how I manage the sites.

  • I think that this post is not properly entitled. I would rather name it "Three Cpanel Security Mistakes You Didn’t Realize You Made", and even though, they are not so common mistakes.
    I personally use cPanel to host 50+ small clients in a dedicated server, and OMG I would never dare to oversell in that way cPanel accounts to multiple clients by abusing of addon domains feature. That would be a very very bad use of cPanel.
    This post, which is totally accurate and fine, is more a "never never do" than typical mistakes made by Wordpress users.

    • Hey Gabriel! There's of course going to be some selection bias inherent to our experience with the web hosting community at large. That is to say, we don't tend to get called in unless something bad has already happened. This exposes us to a significant amount of cases with bad practices like the ones discussed above.

      There's certainly nothing wrong with using cPanel to host websites, and it's got a massive market share for a reason. But considering how many new and inexperienced site owners are encouraged to treat the accounts this way by hosting providers, these are incredibly common situations.

  • I disagree. With most cpanel shared hosting the files are owned by the cpanel account user and the webserver is run as a seperate account.

  • Thanks for the post, I have much to learn by the looks of it!

    Some of this stuff is like learning another language to me and a bloody hard one like Chinese or something!

    All good though, helpful info in the comments too, a wonderful community.

    Xièxiè

  • I do have hosting such as you describe. In fact, I use two different hosting accounts, and both have the addon domains. Some of those addon domains have directory or sub-domains.

    I do have different usernames and passwords for each, and do not have other users on them, so I am wondering if the problem 2 on your article applies,

    "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."

    And I am thinking, yes it does...but want to be clear.

    Also, I am in thinking of creating a reseller account, and load up my sites and customer sites for hosting there. Would that be a problem just like addon domains? I mean, If I opted for one domain for one cpanel?

    Thanks in advance,

    Carlos

    • Hi Carlos! Subordinate reseller accounts, where each site gets its own cPanel by itself, are typically sufficient to prevent infections from spreading easily from site to site.

      Any two applications within the same account (whether they're addon domains or subdomains is unimportant) will have file access to each other, so separating them is safest.

  • Excellent article. Security is so important online now and business owners need to make sure their site, data, and customers are secure on their domains.

  • Thank you for this absolutely excellent post / newsletter. I recently fell victim to issue #1. As a developer (indeed almost any business) the transparency of the internet makes making a profit very difficult. If 123-reg, godddy at al charge £2.99 pm for hosting then how can I justify £5.99? Tough one. So, along comes a hosting service (step forward please Siteground – a villain in this scenario but by no means alone), who offer a flat fee for almost unlimited websites. Suddenly I can play the numbers game – the more websites I cram in the better my margin and the better my chances of competing, until ...
    Three weeks ago I get a malicious code injection. BANG - 35 websites infected. Why does this kind of thing always happen on a Saturday? I spend the ENTIRE weekend cleaning up and restoring from back ups.
    Ok - I was naive. But I feel that sites like Siteground have a responsibility to warn people like me of the dangers of multiple sites on one cPanel – after all, in it's kinda in their interest. Thank you Wordfence for doing so.
    For the record - the last three weeks have been spent pretty much doing the following:

    1. Creating separate cPanels for all my sites
    2. Adding a third party detect / block and clean up WAF to all WP sites
    3. Adding Wordfence to all WP sites
    4. Making sure all usernames and passwords are unique and deffo no 'admin' usernames (honestly there weren't anyway!)
    5. Ramping up my run through manageWP from monthly to weekly for all WP sites

    As it happens I do have a third party back up of all my sites and DBs via dropmysite.com. This was a life-saver three weeks ago as it has been many times in the past.

    Anyhow – three cheers wordfence and looking forward to more posts.
    Martin

  • What would be a good email standalone solution? Thanks

  • I am guilty of #3 and I would like to ensure that
    "the domain user accounts don't own email files for the same domain on the server".

    Can someone help to describe how to ensure this? Thanks!

  • Great article! My web host, SiteGround, says they use suEXEC (http://httpd.apache.org/docs/2.2/suexec.html) on their shared hosting accounts. Is this different from most hosts, and does it help improve security against the things discussed in this article (points 1 & 3)?

  • This was really great info! Thank you.

  • Since you mentioned that it's a bad idea to host multiple sites in one account, I guess you're also against using WordPress Multi User (WPMU) for hosting multiple WordPress sites?

  • As a site owner I like my site to be secured, but unfortunately, I depend completely on my hosting company to keep my site save. These three security mistakes are made in ignorance as the hosting companies do not tell their clients the consequences of these three mistakes that you explained.