Recent WordPress Security Issues – Steps to Avoid Them & How to Fix Them

Recently there’s been a number of high profile WordPress security issues which has led to a massive increase in compromised sites. It’s worth noting that none of the security concerns were to anything to do with WordPress core – all of the issues found were inside of some commonly used plugins.

Some of the Affected Plugins

All of these plugins have several thousand active installs, one of them even reaches well beyond the million mark.

This post contains a list of some well used plugins that had issues in the last few months. Most of these are very recent but there’s one that’s been an issue for over half a year and many sites are still affected.

  • Slider Revolution
  • Gravity Forms
  • WordPress SEO by Yoast
  • FancyBox for WordPress
  • WPML
  • WooCommerse
  • MainWP Child
  • Pods Framework

Slider Revolution and Gravity Forms were 2 premium plugins that were discovered to have vulnerabilities. These 2 plugins are ones that are loved by both end-users and developers so they both have a massive user base.

Gravity Forms is acclaimed to be the best drag-and-drop form plugin because it’s so easy to use, accessible and hookable/customizable where needed. I use it on all of my sites. The Slider Revolution plugin was distributed thousands of times with themes through Envato – it’s also available standalone. 

Gravity Forms had an upload issue that allowed hackers to post directly to it and upload a file so long as the file didn’t end directly with an excluded file extension (so .php was excluded but .php.x would not be). Getting the files onto the server is more than half the battle in situations like this.

The issue was fixed with the release of version 1.9.3.

The Slider Revolution issue allowed hackers to download a full copy of the wp-config.php file (or any other file they wanted) from the server and look at it to obtain database credentials and compromise a site directly via the DB however they wanted. Anything that modifies the database is a nightmare to track down.

/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

I still see requests to my sites using urls like the one above as people still scan the web looking for vulnerable sites.

This issue was patched in February however it was disclosed and exploited for a long time before it was patched. Versions 4.0.2 or above are no longer vulnerable.

Part of the issue with this particular plugin is that it was bundled with many themes and because it’s not hosted by wordpress.org there are no automatic update notifications. Many site owners are not aware that there’s even a problem.

Yoast’s WordPress SEO plugin is a hugely popular plugin – a freely available one through the wordpress.org repo. I install it on all of my sites, all my clients sites and recommend it as a must to anyone else with a self-hosted WordPress site.

A vulnerability was found that would potentially allow a hacker to execute a blind SQL injection attack on the site and compromise the site through executing commands on the database.

Since the plugin is entirely open source and hosted on GitHub this was patched and released quickly to everyone affected. There are literally millions of sites using this plugin so WordPress.org pushed an automatic update out for it.

If you’re on version 1.7.4 or higher your site is no longer vulnerable.

The FancyBox for WordPress plugin took a serious hit with a zero day vulnerability used to upload and execute code on the site’s hosting server.

Updating to version 3.0.4 or higher solves the issue.

Another plugin that had several serious vulnerabilities was the WPML plugin. Exploiting it allowed SQL injection, post deletions, reflected XSS and unauthenticated admin access to certain functions.

These issues were fixed with version 3.1.9 – if you’re on that version or higher your protected.

WooCommerse had a flaw that opened an SQL injection vulnerability. It was found by a researcher at WordFence and was fixed in a matter of hours by the development team at WooThemes. That’s exactly how it should be done.

The MainWP Child WordPress plugin has over 90 thousand installs and had an issue that would allow a hacker to login to a vulnerable site bypassing the WordPress password authentication mechanism entirely and get access to the dashboard.

Pods Framework proactively took the opportunity to do a security review of the plugin following the discovery of the blind SQL injection vulnerability in Yoast’s SEO plugin. They discovered a similar issue and quickly pushed an update.

Versions 2.5.1.2 was released with a security fix however it’s extremely refreshing to see that even older versions of the plugin can be patched with download packs available on the resources page of the plugin site.

Ways to Find out if your site is Compromised

There are a few online tools that can run world facing scans of your site to detect malware. I routinely turn to Securi to run quick external site scans. There’s also plugins to check your site’s filesystem for problems. I suggest you do use both of them as one of them is likely to find an issue there are any.

Sometimes (particularly with world facing scans) there will be things missed. If initial scans fail to flag anything and your still not convinced the site is clean then the hacker has probably done a good job at hiding their presence. Hackers tend to be quite good at hiding things because the longer they stay hidden the longer they can make use of their victims.

A clever hacker will use several methods to prevent detection. The most common would be encrypted (or obfuscuted) code. With anything world facing there’s generally a referror and user agent check that happens somewhere too which helps prevent world facing scans detecting it.

With referror/user agent checking a hacker can hide from a site owner. Owners will almost always arrive on their site via directly typing the url – if a hacker checks referrer (or logged in status) and only outputs to those people who arrive with a referrer from off-site then the owner may never see it.

Similarly if it checks the user agent for something that is obviously a bot (say for example GoogleBot) then that bot may never know the site is infected. In the case hiding from GoogleBot they can prevent search engines from showing a safe browsing warning – keeping search engines sending traffic that can be exploited.

One way to try and make sure that any injected content will show for you when you suspect that a site might be compromised is to arrive on your site exactly how ordinary users would. That might be through a link on another site but probably through a search engine.

Make sure you’re logged out of your site and then find it through a search engine. Visit the site through several different links (or search terms) and check the page for any injected content (particularly links that shouldn’t be there and javascipt that is included). If the search engine has found a problem then you’ll probably get a warning before visiting the site if not you may be able to find something that has been injected.

What to do About the Issues & How to Avoid Them

All of the plugins I mentioned here are actively developed, maintained and used throughout the WordPress community. When vulnerabilities are discovered they are generally patched quite quickly.

Fixes can be available for users within hours – and in the case of plugins available in the wordpress.org plugin repo they can automatically be pushed out to everyone affected when the situation is dire enough – like was done with the recent WordPress SEO plugin issue.

You should regularly check for updates and run any on your site that are available. That’s the best protection against known vulnerabilities.

In the case of zero day vulnerabilities (which are vulnerabilities exploited before they are publicly disclosed and/or before the developer knows about them) there isn’t a sure fire defence. The best you can do is monitor for suspicious activities on your site, check for anything unusual in your server logs and definetly be vigilant with checking and backing up.

Note that even themes and plugins that aren’t active can still be used to find a vulnerability because in some situations hackers can request or POST to them directly. Either remove unused ones or keep them updated.

What To Do With A Compromised Site

Because of vulnerabilities like these lots of sites are being targeted and used for a number of things from spreading malware and redirects to pharma-hack style links to spamming emails from the server. Once a site is compromised anything is pretty much fair game for a hacker.

First off I hope that you have a backup. This is the prime example of why backup plugins aren’t for backing up – they’re for restoring. If you have a backup the process of removing a hack and getting rid of the infection becomes much easier.

Deploy a backup from before the site was infected, update plugins and themes to hopefully close any vulnerabilities and change the database and user account passwords. You should be good to go providing the issue isn’t a zero day vulnerability.

If You Don’t Have A Recent Backup

If you don’t have a backup then I’d suggest you consider redeploying an old backup and rebuilding any content or changes to the site since that point.

If you really don’t have any option to deploy a backup then I suggest the best thing to do right away is change passwords for user accounts and the database – that may help reduce the chances of reinfection but it’s very likely that other backdoors have been installed.

Update WordPress, your themes & plugins then run a scan on your files for potentially malicious changes (modification time can be a clue here as to when the site was compromised).

Compare the files in your install against the original files for differences. There are plugins available that can do this for you with a detection mechanism used to spot things that might be malicious. WordFence is what I use as the first step of filesystem scanning. Make sure to deal with any issues that it shows, particularly when it tells you that core files or opensource themes/plugins have been modified – that’s a sure sign of something untoward.

The rest of the clean-up is going to differ depending on what kind of hack has been done to your site (and it will even differ from hacker to hacker). With a little luck the only infections will be inside executable files that are on the filesystem. The alternative is having to clean up check even files that aren’t normally executable (in particular the image files) and the database in addition to the filesystem.

Finding infections or backdoors inside the database is much more complicated and can be a far more daunting task. There’s even situations where there might be content added that does not execute or do anything malicious (such as links are injected into the content of pages or posts) that can be extremely hard to pinpoint and can have an awful knock-on effect to the site’s search rankings.

Making sure you get everything can be a major annoyance so once you’ve done all of that that you really need to monitor server logs for requests to unusual files, keep track of user logins and use an analytics package to track outbound clicks for anything suspicious. Monitor and block anything that looks even remotely suspicious.

At this point in time again it’s a good idea to change user and database passwords again – even if you done it before.

If You Can’t Clean Up The Site Yourself

You can contact a specialized security company to get help. My personal recommendation is Securi. They will clean up your site and offer protection from future attacks as part of a single subscription. They will even put your site behind their firewall and make sure all known attacks are blocked.

You can always contact me on this site and ask me for help with the clean-up or visit my main WordPress Development site and contact me there. I keep up-to-date with WordPress security news and have seen many different methods of infection that used dozens of different vulnerabilities to accomplish the hackers plan. I can probably spot patterns of infection quickly and help to deal with them ASAP.

Disclosure: The link to Securi is NOT an affiliate link and I will receive no compensation if you purchase through the link. I am not otherwise affiliated with Securi nor have I ever worked with or for them – I just think they are the best company to go to if your WordPress site needs cleanup or protection.

Varnish CDN

A while ago I wrote about an idea I’d had to make use of the Varnish forward caching proxy as a CDN. As it happens I’m not the only one who’s had the idea. There are companies offering Varnish as a CDN in SaaS (or IaaS) form out there but the prices I seen for the minimum offerings were definitely above the average WordPress site’s CDN requirements and budget.

If other companies are using a similar system and charging for it then it seems like the idea is a good one. As it happens it’s not all that hard to implement. In fact this very site is using Varnish as a CDN right now (inspect the page and look at one of the static resources in the network tab and you should see some Varnish Headers).

A bit of testing testing and configuration and 2 hours later it was ready to be put in production. A single DNS change to point it towards the Varnish Server and it was live.

Using Varnish as a CDN

Update – 22/02/15: This site now uses a Varnish Backed CDN. Turns out it was pretty strait forward to implement 🙂

Varnish is a front-end caching proxy that serves only static content. The way it works is not too far removed from how the top level server operations work with an origin-pull CDN.

A CDN server receives a request for a static file and it delivers it. If the file us on hand then it sends it, if it isn’t available then it pulls the file from the origin and serves that while storing the file it in it’s cache. That’s basically what Varnish does as well.

I’ve had this idea for a while but only recently added a spare Varnish caching proxy to my cluster that I can use for testing.

The primary server will be the one rewriting urls to point to the CDN domains.

I already have a basic statics server set-up and running on a separate box from the main domain. It’s got a push-style propagation method, is configured with long expirations for files and doesn’t accept cookies.

That already gets populated with files so I’ll use that as the origin to keep the busy worker count on the main server down. I want about half the requests to hit the statics server and half to hit the varnish server. The main domain will be the one that handles rewriting to make that happen. I may use the W3 Total Cache plugin to do it through PHP or I might use mod_pagespeed domain sharding through Apache.

Using Pagespeed for it has it’s benefits but it would likely be a much simpler set-up process if done with W3 Total Cache.

The statics server already gets filled with it’s files (initially filled with rsync and kept up to date by W3 Total Cache – rsync runs on cron to make sure the files are always the latest versions). The Varnish server is not primed when it starts like the statics server is. We need to tell Varnish where it can find the files it doesn’t have.

To do that a backend is set that points to the statics server and Varnish gets told that when a request arrives on a specific domain and it doesn’t have the file in it’s cache then it should request from a specific server then cache it and serve from the cache next time.

Once things are set-up and the Varnish cache has been running for a while it’ll serve the function of being a 2nd node in the Content Delivery Network. The benefit of doing it this way is the ability to add extra nodes with ease and they can be put to use like I’ve described, behind load balancers or with GeoIP targeting all with minimal configuration.

That’s the basic idea in a nutshell. In reality things are a little more complicated. There’s on-the-fly optimizations done by the upstream server that get performed by mod_pagespeed and likely a need to create some kind of tweaked LRU eviction function for Varnish so that it’s cache doesn’t fill with multiple versions of the same file at various different optimization stages.

I’ll deal with the problems as I come across them but there’s no harm in testing the idea and building the system. The potential performance increase for a small single site is probably negligible but across an entire network of sites it’s likely to amount to a substantial performance improvement all round.

Programmers Effieciency

The efficiency that a programmer demonstrates in their code could be misconstrued in the real world as laziness.

As a programmer one of the things that we try to do is solve problems or perform a task in the most efficient way possible. In computing terms efficiency generally bogs down to doing it in less code or doing it with less CPU cycles.

Knowing how programmer efficiency could be perceived by other people I tend not to point out the basic though process I go through whenever my wife asks me to do something. It’s best if that never gets declared globaly lol.

“What’s the quickest way possible to get this done?”, “Do I need to do all of these steps or are some unnecessary?” or

  • “Would looping small sections of tasks instead of doing it one big block be better?”
  • It’s not lazyness it’s efficiency… at least that’s what I tell myself in my head.

    Trying The Twenty Fifteen Theme

    Well I’ve just started a brand new personal blog and thought: What better time to try out the next default theme?

    Twenty Fifteen is shipping with the beta version of 4.1 that you can try out by installing the beta plugin and setting it to bleeding edge nightlies.

    It’s clean… really clean… like nothing to it kind of clean. And that’s the main problem, there’s basically nothing to it. It demonstrates a really nice use of the WP Customizer – allowing you to select a colour scheme from their predefined palette (or tweak each colour to a custom value if you want), upload and use a custom header or background and set menus in 2 theme location.

    It only has the option of a right sidebar and both menus go in there along with the widgets you pick. The primary menu is basically like a blogroll from the old days.

    The second menu is a social icon menu. It will automatically parse what social network you have linked and display it as an appropriate icon – instead of a plain old text link. That’s a pretty cool feature, probably the coolest thing about the theme if you ask me, but I only use Twitter so it’s wasted on me.

    It’s built mobile first so it gets a +1 from me for working that way but design-wise it’s really not to my taste.

    All of the default post formats are enabled though so maybe that’s the way to go when it comes to customizing your site if you use Twenty Fifteen.

    In theory taking the default theme back to it’s blogging roots and making it über clean and streamlined is a great idea. In practice it appears not to work all that well.

    I’m crossing my fingers that a lot changes are made between now and the official release of the theme but I won’t hold my breath. There’s not been a great deal of talk on Make WordPress Core about changes and it’s slated for release with WP 4.1 in December – which doesn’t leave a lot of time to do much about it.

    Since Twenty Fifteen is scheduled for the end of 2014 maybe the could start working on Twenty Sixteen early next year… heck maybe I should hop on over there and push to try to have some input into what Twenty Sixteen should be like.