WordPress Security – Cutting Through The BS
I recently spoke at WordCamp Chicago 2012 and did so 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 spot, 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, and 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 as of late, 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 points of consideration. 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 looks like:
- Linux
- Apache
- MySQL
- PHP
Also known as a LAMP stack. This ofcourse is very rudimentary, but important to point out because in each of those instance 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 at fault in this instance?
Ask yourself, how would all the WordPress specific hardening protected 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 its by far the most important in my opinion. I actually wrote a post a while back about understanding the true vulnerability with WordPress. In it I highlight the end-user as the weakest link in the security chain, nothing has changed that perspectives.
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 its a completely different story. In fact, I would likely categorize each in order of importance as follows:
- End-user
- Plugins
- Themes
The challenge begins with the end-user. Whether its 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 any one use WordPress? All I hear 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 soften and sugar coat the reality of the web security is likely contributing to the message not reaching the massess the way it should, and by should I mean enabling change. I did point out though that being afraid or worried as not the appropriate course of action and reassured her that the various other competing applications faired far worst in some instances.
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. There in 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 is Key
- Blacklisting
- 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 employe 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?
- SFTP/SSH is the ideal solution
- Employ least privileged
- 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
- Backdoors
- Injections
- Pharma Hack
- Malicious Redirects
- Defacements
- 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
- Access
- Vulnerabilities
- Leverage a server web application firewall (WAF)
- Leverage an application web application firewall (WAF)
- Use Two Factor Authentication
- Strong / Unique Passwords
- Employ least privileged principles
- Stay Up-to-Date
- Use Trusted Sources
- Avoid Soup Kitchen Servers
- Segregate your environments
- 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.
- 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
- Go with a managed solution
- Hacked Tag – http://wordpress.org/tags/hacked
- Malware Tag – http://wordpress.org/tags/malware
- BadwareButers – https://badwarebusters.org
These were chosen because of their relevance and impact to all end-users, regardless of platform.
Hosting is the obvious discussion point because of its impact, 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:
These are questions that I’ve put together based on engagements with clients every day.
Connecting it the next most important things that most end-users and developers seem to fubar on a daily basis.
The biggest take-aways can be boiled down to two recommendations:
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. Its the idea that when you log into your administrator panel to put out a post you don’t need to do so under the 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 groups: Opportunistic and Targeted. Each has its own market and purpose, some have bigger value than others to employ.
The take-away for the attendees though was that they all likely fell 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 log in credentials or exploiting remote file inclusion vulnerabilities like those found in TimThumb, its through automation that most attacks occur.
Blacklisting earned a right on the presentation. With close to 6,500 sites being blacklisted daily its 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 its not good to lose your mind. Contrary to popular belief, its not the end of the world, as much as many might like you to believe.
Yes, it will impact your brand, that’s a given, but its 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, it was designed to explain what today’s exploits consist of for WordPress. It does not outline every possible infection or vertical, it’s be too time consuming and who the heck wants to read that much security crap anyway.
Own one Own them all
For WordPress, today’s exploits are as follows:
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 its 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:
The vectors for these infections should be of no surprise to any one:
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 app 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 most overlooked issues today. We wrote a post describing how cross-site contamination works, I’d encourage you to read it to gain a better perspective and appreciation for the challenge.
Compromised credentials continues to be an issue, but not just on your wp-admin access point. 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 a RFI vulnerability I can pass commands 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 advise 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 advise to users:
After giving it some more thought, I would also add the following:
In regards to vulnerabilities, this one is a hard nut to crack. The obvious advise 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:
A bit soft, I know, but together can be very effective.
My Final Take-Aways
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 take-aways.
So I broke my advise 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:
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 then do the following:
Understand though that a managed solution does not imply you’re inheretingly secure now, it just means you have some one that will back you up and take the worry off your plate, well at least the worry of “What the heck is happening?” syndrome. For a list of hosts that offer this server and have partnered with us please check out our partners page.
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]
<FilesMatch *.php>
Order Allow, Deny
Deny from all
</FilesMatch>
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:
Public Forum:
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:
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.
Thanks for stopping by and if you have any questions please leave us comments or send us a note at info@sucuri.net.
Read more: WordPress Security – Cutting Through The BS
Incoming search terms