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.
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.
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
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:
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:
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:
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:
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.
There were five other things I touched on and very carefully selected for this presentation, they were:
- Your Host
- Attack Type
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.
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:
- Pharma Hack
- Malicious Redirects
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:
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.
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:
- Kill PHP execution
- Disable Theme / Plugin Editing via Admin
- Connect Security – SFTP / SSH
- Use authentication keys in wp-config
- Use Trusted Sources
- Use a local anti-virus – Yes, MAC’s need one also
- Verify your permissions are set right (Directory 755 / Files 644) – important for cross-site contamination issues
- Practice least privileged
- Kill generic accounts
- For the love of all that is holy to you, back up your site.
Dear Paranoid Few here is what you need to do:
- Do everything your cousin Average Joe did
- Don’t let WordPress write to itself
- Filter by IP – server / app level
- Used a dedicated server / VPS
- Employ WAF’s
- Employ SSL
I think I would also add a new message to The Confused:
If what we have written above makes not sense or you feel a level of distress, please do the following:
- 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);
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:
- Hacked Tag – http://wordpress.org/tags/hacked
- Malware Tag – http://wordpress.org/tags/malware
- BadwareButers – https://badwarebusters.org
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:
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 firstname.lastname@example.org.