WordPress Security – Cutting Through The BS

Update 9/9/16:

We released a new guide that provides better instructions on how to clean a hacked WordPress site using the Free WordPress security plugin.

Update 11/3/2017:

Proud to share with all of you our newest WP Security Guide that provides insights on vulnerabilities and the latest best practices to protect your website.


I recently spoke at WordCamp Chicago 2012 on WordPress Security. In this post I’ll share my presentation but also provide context such that it allows the reader to better digest the presentations content.

Let me know how I do!

When putting the presentation together I found myself between a rock and hard place, I felt as if all the presentations given to date are always about the same stuff. And maybe that’s necessary, repetitiveness is key they say, but is it?

When was the last time we really sat back and thought about the recommendations we’re giving to the end-users, myself included. I’d venture to say it’s been a while. More likely than not, at least from the various presentations I have spent time looking at, it’s no more than a regurgitation of another presentation.

So with that, I found myself on quest to siphon through what I like to call The BS.

The Preso

Please note that because of the time constraints I had to be very selective on the components of security I felt most pertinent to my story, there are obviously many others that had to be left out. My goal was to provide end-users a comprehensive understanding of web security and how it pertains to WordPress.

Knowledge

The meat and potatoes starts on slide 5.

Something I don’t often see in security presentations is the general awareness that comes with Information Security. Specifically, the importance of educating the user on the ecosystem that is their environment.

Disclaimer: This presentation is good awareness for everyone, but is likely most applicable to those that run their websites on shared hosts, dedicated or VPS servers, managed WordPress hosts, and other similar configurations.

“The user’s going to pick dancing pigs over security every time.”
– Bruce Schneier

The Environment

Slides 6 – 7 were designed to bring home the point of how big the threat-scape is. It begins by taking a look at a basic server configuration for WordPress. It looks like this:

  • Linux
  • Apache
  • MySQL
  • PHP

This is also known as a LAMP stack. This is a very rudimentary configuration, but important to illustrate because in each of those logical components there are known vulnerabilities.

Case in point, here are some examples:

These are two very different vulnerabilities, each have nothing to do with WordPress, but because of them a number of WordPress sites were afflicted with malware issues. So who is really at fault?

Ask yourself, how would all the WordPress-specific hardening protect you here? The answer is, if you’re only focusing on WordPress you’re doing it wrong and the answer is nothing.

The next obvious place to look is at the WordPress architecture.

When I break it down I classify them into four (4) distinct domains:

  • Core
  • Themes
  • Plugins
  • End-user

While end-user is not really a logical component of the architecture it’s by far the most important, in my opinion. I actually wrote a post awhile back about understanding the true vulnerability with WordPress, still very relevant today. In it I highlight the end-user as the weakest link in the security chain, nothing has changed in that regard.

It has been many versions since WordPress core itself had a substantial vulnerability worth mentioning. Most of today’s issues are isolated to the administrator role being able to hack itself via XSS, CSRF or SQLi type exploits. This in itself greatly reduces the severity of a vulnerability.

You then turn your attention to the themes,plugins and end-users and it’s a completely different story. In fact, I would likely categorize each in order of importance as follows:

  1. End-user
  2. Plugins
  3. Themes

The challenge begins with the end-user. Whether it’s a set of compromised credentials, installing a bad plugin, not monitoring comments, installing a bad theme, etc.. Then there are the instances of plugins, followed by themes that introduce new vulnerabilities into the environment. Perhaps the most notorious being the introduction of TimThumb via Themes and Plugins.

Then the idea was to step back beyond the immediate environment and application architecture and look at a more realistic configuration. In doing that we gain a much deeper appreciation for how complex the threat-scape is. Here is a very abbreviated list of applications you might find in your server at any given time if you’re hosting with any of the common hosts:

  • WordPress
  • CPANEL
  • PLESK
  • PHPMyAdmin

What you likely don’t realize is that each one of these are able to contribute to the insecurity of your website. The most notable vulnerability as of late being PLESK. While we’re still trying to grasp the impact this vulnerability had to website owners, like those reading this post, we do know it was substantial.

I had a nice lady at the presentation stand up at the end of the presentation and ask:

… Why would anyone use WordPress? All I hear is how easy it is and here you are scaring the [explicative] out of me.. – nice lady

She’s right, in that I likely scared the [explicative] out of her and a good number of others in the room, but is that wrong?

I would argue that perhaps our attempt to sugar coat the reality of web security is likely contributing to the message not reaching the masses the way it should, and by should, I mean enabling change. I did point out though that being afraid or worried was not the appropriate course of action and reassured her that the various other competing applications fared far worse when it came to security.

And, to be clear, the message is not that WordPress is vulnerable or insecure, but rather that you as the end-user have more responsibility than you, and many others, care to admit or accept. Therein lies the problem for me.

Some Basics

There were five other things I touched on and very carefully selected for this presentation, they were:

    • Your Host
    • Connecting
    • Attack Type
    • Automation
    • Blacklisting

These were chosen because of their relevance and impact to all end-users, regardless of platform.

Hosting is the obvious discussion point, everything described when talking to the environment, for the most part, falls within the host umbrella. It has to be a symbiotic relationship between you and your host, or you’re starting things off very wrong.

If you don’t know what you’re doing, go with a managed solution!! – Perezbox

There are obviously a number of questions you should be asking yourself and your host when looking into entering a relationship but I focused strictly on those that pertain specifically to web security:

      • Who is your host? – more a question for the end-user, “I don’t know” is not a good answer
      • How do they manage connections? FTP, SFTP, SSH? Other?
      • What security does your host use? Do they employ application or physical web application firewalls?
      • What is your hosts approach to a compromised site? Will they disable the site? Ban you from the server?

These are questions that I’ve put together based on engagements with clients everyday.

Connecting is the next most important thing that most end-users and developers seem to fubar on a daily basis.

The biggest takeaway can be summarized in two recommendations:

      • SFTP/SSH is the ideal solution
      • Employ least privileged

Everything else is noise, but don’t just gloss it over, it’s good noise.

Least privileged is the act of using the lowest possible role and likely the one thing that no one seems to place any emphasis on. It’s the idea that when you log into your administrator panel to put out a post you don’t need to do so using an account assigned an administrator role. There are a number of other plausible roles; learn to use them effectively.

I placed emphasis on Attack Type because I felt it was important to understand the nature of today’s attacks. They can be categorized into two groups: Opportunistic and Targeted. Each has its own market and purpose, some have bigger value than others to employ.

The takeaway for the attendees though was that they all likely fall within the opportunistic category. Unless you’re a large entity with an equally grand online presence. The odds that you would experience a targeted attack is slim to none. That being said, this does not include attacks that come from someone you pissed off or fired.

In either case, automation is key. Whether through brute-force / dictionary attacks against your login credentials or exploiting remote file inclusion vulnerabilities like those found in TimThumb. It’s through automation that most attacks occur.

Blacklisting earned a right on the presentation. With close to 6,500 sites being blacklisted daily it’s important that we bring awareness to the issue.

Take a chill pill.. Not the end of the world.. – Perezbox

It’s good to understand the various warning messages, but it’s not good to lose your mind. Contrary to popular belief, its not the end of the world, as much as many might lead you to believe.

Yes, it will impact your brand, that’s a given, but it’s a momentary blip in the grand scheme of things. Upon getting the notice from Google, or a friend that notices, take the appropriate steps to get yourself cleaned up. It’s a bit of a blackhole working through the webmaster process as the detection and reindexing appears to be mostly automated, but it works. Be patient and do what you can to insure you are clean before submitting to Google for review. There a number of online services you can call upon if you need a hand, ourselves included.

The How


This entire section was a bit more straight-forward, designed to explain what today’s exploits consist of for WordPress. It does not outline every possible infection or vertical, it’d be too time consuming and who the heck wants to read that much security anyway.

Own one Own them all

For WordPress, today’s exploits are as follows:

      • Injections – SQL, Link, iFrame
      • Remote File Inclusion – Think TimThumb
      • Remote File Execution – Ability to pass commands to a payload on your server and bypass your security
      • Brute Force / Dictionary attacks – exploit access points

You have to understand though that exploits are not just things your application is susceptible to. Go back and review the environment discussion, these and many more impact those components as well. The same exploits being used against WordPress and its components are being used against the various components outlined in the presentation. This is why it’s so important to understand and deliver a complete message to all end-users.

With an understanding of the exploits, we turn our attention to the infections most affecting WordPress installs. I categorized them into the top 5 infections we see and is based on remediation cases we see daily:

      • Backdoors
      • Injections
      • Pharma Hack
      • Malicious Redirects
      • Defacements

The vectors for these infections should be of no surprise to anyone:

      • Vulnerable software – not synonymous with out-of-date software, but related
      • Cross-Site Contamination – Soup Kitchen Servers
      • Compromised Credentials – FTP, SFTP, SSH, WP-ADMIN, CPANEL, DB
      • Remote File Inclusion – TimThumb, Uploadify

Make note of my emphasis on the use of vulnerable software in the place of out-of-date software. Yes, it was intentional, the vulnerable state of the application is what is leading to these compromises, not so much the fact that it is out of date. That being said, it is fair to say that patches and updates do often address a number of security concerns and allowing yourself to become out of date does increase the odds of a compromise.

38% of us would rather clean a toilet than think of a new password! – Mashable

The other vector most don’t consider is the concept of cross-site contaminations. This issue is just too common these days, which is a bit amazing when you consider the relative inexpensive nature of hosting. Yes, we have seen this across experienced and well-known WordPress developers and companies as well. It’s, for whatever reason, one of the more overlooked issues today. We wrote a post describing how cross-site contamination works. I’d encourage you to read it to gain better perspective and appreciation for the challenge.

Compromised credentials continues to be an issue, but not just on your wp-admin. A user must be thinking of all access points, their FTP, SSH, SFTP accounts; don’t forget CPANEL, it’s just as important, if not more so. Database access – one vector most forget – but as illustrated earlier is just as susceptible as well. Most of these are being conducted through brute-force / dictionary type attacks and lends itself to today’s password dilemma.

Then there is the infamous TimThumb, and its distant cousin Uploadify. The type of vulnerability that TimThumb introduces is known as a Remote File Inclusion and with it a number of issues are introduced. One such issue is the ability to employ remote execution to payloads dropped into your environment via the RFI vulnerability. In short, using an RFI vulnerability, commands can be passed to your server and further exploit and override all your hardening steps – a bit depressing, I know. But what’s important to note here is that although TimThumb is by far the more popular instance of this, there are other instances of similar vulnerabilities found across a number of plugins.

Good resource to stay on top of vulnerabilities include:

Make It Stop

This is where most of my rub with the advice being given comes into play, that being said I’ll keep it as objective as possible.

The question isn’t who is going to let me; it’s who is going to stop me

In the spirit of keeping things simple, I broke it down to two categories:

      • Access
      • Vulnerabilities

One is obviously more objective than the other for a number of reasons.

In each case I tried to think about the things that would contribute to a secure environment, and to do so you must accomplish both verticals.

So to ascertain a secure environment from an Access perspective this is the advice to users:

      • Leverage a server web application firewall (WAF)
      • Leverage an application web application firewall (WAF)
      • Use Two Factor Authentication
      • Strong / Unique Passwords

After giving it some more thought, I would also add the following:

      • Employ least privileged principles

In regards to vulnerabilities, this one is a hard nut to crack.

The obvious advice is to stay up to date, but it feels so easy to say and it doesn’t address zero-day vulnerabilities. With that in mind, here are my thoughts:

      • Stay Up to Date
      • Use Trusted Sources
      • Avoid Soup Kitchen Servers
      • Segregate your environments

A bit soft, but together can be very effective.

Final Takeaways

When you wrap all this up, what do you get? A pretty good orientation of WordPress Security, and that was the intent, but I’d be remiss if I didn’t provide some more tangible takeaways.

So I broke my advice into the Average Joe and what I would tell the Paranoid Few. Which one are you?

Dear Average Joe here is what you need to do:

      1. Kill PHP execution
      2. Disable Theme / Plugin Editing via Admin
      3. Connect Security – SFTP / SSH
      4. Use authentication keys in wp-config
      5. Use Trusted Sources
      6. Use a local anti-virus – Yes, MAC’s need one also
      7. Verify your permissions are set right (Directory 755 / Files 644) – important for cross-site contamination issues
      8. Practice least privileged
      9. Kill generic accounts
      10. For the love of all that is holy to you, back up your site.

Dear Paranoid Few here is what you need to do:

I think I would also add a new message to The Confused:

Dear Confused,

If what we have written above makes not sense or you feel a level of distress, please do the following:

      1. Go with a managed solution.

Understand though that a managed solution does not imply you’re inheritingly secure now, it just means you have someone that will back you up and take the worry off your plate, well at least the worry of “What the heck is happening?” syndrome.

Kill PHP Execution

I have mentioned it before and this is by far the most effective hardening you can apply that will really do something for you:

#PROTECT [Directory Name]
 <Files *.php>
 Order Allow, Deny
 Deny from all
 </Files>

This ensures that PHP files can not be executed from within a directory. Do note that it could break your theme or plugin, so you’ll want to use it sparingly, but at minimum try using it in your wp-includes and uploads directories.

Disable Editing in /wp-admin

I am also a big fan of this. Too often we’re seeing wp-admin credentials compromised and by allowing someone to edit within your admin panel you give the attack full access to all your files. The easiest way to avoid this is to disable the editor via your wp-config file:

#Disable Plugin / Theme Editor
 Define('DISALLOW_FILE_EDIT',true);

Shit Happens


Yes, contrary to popular belief, it does happen. More often than most might want to admit actually, to small and large companies alike. Some say its inevitable, just look at our poor friends at Oracle.

So here are a few recommendations on places you can go for help:

Support Forums

WordPress Forums:

      • Hacked Tag – http://wordpress.org/tags/hacked
      • Malware Tag – http://wordpress.org/tags/malware

Public Forum:

      • BadwareButers – https://badwarebusters.org

Live Scanners

While not a preventive tool, detection is a part of stay ahead of the malware problem. Be mindful of scanners that are not live, here are two that can prove to be helpful for you:

It’s also important to note the various blacklist entities out there, not all are the same, here are a few:

      • Google – Chrome / Firefox
      • Bing – Internet Explorer / Yahoo
      • AVG – Opera

If you’re feeling a bit cheeky and want to have a go at some cleaning, be sure to leverage some of our Tips & Tricks to help you get started. But if you find yourself needing professional help, remember to make sure you have everything you need to effectively engage and get the problem addressed.

If you have any questions please leave us comments or send us a note at info@sucuri.net.

28 comments
  1. I don’t take the time to read article such as this one where the author does not take the time to write in a grammatically correct way. And BTW, the profanity does not help either.

    1. But you take the time to comment on it?

      This is a REALLY good article on WordPress Security. If you skip it for grammatical mistakes, you are really cheating yourself.

    2. Hi Greg

      Wow, didn’t realize it was so bad that it turned you away. I’m going to read through it again, see what I might have missed that caused you to react this way.

      Thanks for pointing out your concern over the grammar.

      Cheers

      Tony

  2. Hi Tony, sorry I missed you at WCChicago. Outstanding article here, and greatly appreciate your services and “no-BS” approach. We’ve sent over a few of our customers this week who were “newbies” to WP and found themselves on the wrong end of some backdoor malware. Your team handled things asap, and turned lemons into lemonade. We’ll be working your strategies into our client advice, and recommending your services to our other clients as well.

    Cheers!
    spence

  3. Wow. If this is your “no BS” approach….I hate to see the long version. Just once, I’d love to see an article written by you that is shorter than the average novel. I realize the topics you write about require a lot of information, but for Christs’ sakes….there are tons of other Internet Security professionals who seem to tackle these same topics just fine, and without putting me to sleep in the process.

    1. Most of what is here can be reduced to practice with, well, practice. Some of the article covers SOP, which is portable and platform independent. That is, learn the principles of security with WordPress, and apply them to any other web application.

      1. Tony is known for having a lot of security knowledge, and also for trying to impart everything he knows into every article. This article is no different… it’s ridiculously wordy to the point of tedium. Every article doesn’t need to reinvent the security wheel. That speaks less of trying to educate the public, and more of his ego.

  4. The slideshow was MUCH easier to follow than your overly wordy article. Since you’re using WordPress here yourself, why not make use of it’s word count feature on posts?

  5. Tony, I hunt everyday for online resources that help with wordpress security; I locate some, like I did yours and then my heart sinks! Very few seem to even care for WordPress installations done on IIS.
    Is this something you will someday address?

  6. Great article! I know its a couple of years old but very informative. I saw some less than thrilled comments, but you handled that with grace and patience. Top marks young man!

    regards

    JIm

  7. Hi Tony. Very nice well-written article about WordPress security. I do run WordPress in my own VPS and did everything to minimize attack surface.

    Considering what you’ve written:

    “Yes, MAC’s need one also”

    I take it you mean Media Access Control? If you mean “Mac,” instead of “MAC,” that makes a lot of sense. Even better for clarity, what about “Mac OS” or “Mac OS X?”

  8. Thanks Tony! great article. The presentation slides didn’t work on my browser but I’m glad for the text. It really helped me. Honestly for a newbie, like me, going over the basics of internet security was helpful too.

Comments are closed.

You May Also Like