The Achilles Heel of WordPress (or any site)
Over the past couple of weeks I have been playing a game of cat and mouse with hackers who managed to introduce malware into a number of WordPress blogs that are hosted on our Cloud servers. I later discovered that another site – not a WordPress blog – had been similarly hacked. The game of cat-and-mouse ensued because every time the infection was removed it returned within 24 hours. For about a week this continued and appears to now have subsided.
There are a number of vectors at play here, but they resolve to 2 main attack paths:
- Third-party plugins within WordPress
Both of these elements have something in common: they are both public, open source code and are outdated versions.
The problem; you’ve been framed
The problem arises when you use third-party, open source code. Over time, hackers find ways to exploit this code and then set up a botnet (or equivalent) to scour the web for installations of the outdated, third-party code and duly infect the website that contains it. These botnets can continue their activity for a period of time, which accounts for why these WordPress (and other) sites were repeatedly hacked every time the code was replaced with a clean copy – it still contained the outdated, third-party code.
For WordPress, the vulnerabilities are many and multiform as each installation can be customised with as many different plugins as the website owner, developer or designer wants. These third-party plugins may or may not be maintained, and can themselves contain further third-party code, and so on to many levels. Even if the plugin is maintained, any third-party code that it contains may not be updated and so propagate the vulnerability.
Aside: In my case, it appeared that the WordPress plugin Jetpack had been targeted and, according to the logs, was the attack vector the hackers used to overcome the site, though ‘the timthumb hack‘ is the most likely third-party candidate. After I removed it (and its associated plugins) the attack subsided. In the other sites, it was the use of a third-party system that required an old version of jQuery (because it did not work with the later versions of jQuery) that caused the problem.
The implications; you’ve been maimed
When your site is infected you become a ‘bad place’ (eventually) according to Google and other repositories that monitor malware on the web. Many desktop anti-virus systems (e.g. Kaspersky) scan the web pages you visit for problems and block the page from your visitor, and in turn report the site as ‘bad’ or ‘harmful’. In time, browsers such as Chrome simply put up a warning page that the site may be harmful if the visitor proceeds and you get next to no visitors. Unfortunately, the Google Webmaster Tools which have been hailed as an early-warning system for such incursions don’t seem to be flagging them even though Chrome does (we monitor all our sites using Google’s Webmaster Tools and all were showing as ‘clean’ according to their malware report even though Chrome was showing a ‘warning, bad site ahead’ page).
The solution; you’ll be tamed
The best option is to keep your website (WordPress and plugins, or any third party code) fully updated to minimise the possibility of allowing hackers to exploit existing vulnerabilities. However, that requires maintenance which may in turn incur costs from your web developers. Content management systems such as WordPress itself gets frequent updates to minimise risks (which makes the core framework stable and secure), and contain an auto-update feature which makes life very easy. Third-party plugins are designed with this auto-update feature also, but may be less often maintained and therefore introduce greater risk. Choose which plugins you need wisely to minimise the number of potential vulnerabilities.
If you have a bespoke application, you should ensure that your web developers maintain any third-party code to reduce the risk of being hacked. After all, if this happens you could easily be offline and invisible on the web, or worse (your database could be hacked, information stolen, etc, etc.). This maintenance will incur additional costs unless you have a support agreement in place, but is a necessary evil on the Web today.
If your WordPress installation has been hacked, you will first need to recover your site. The code that runs it is relatively easy to fix – delete the site and replace the code with a fresh installation. The database is a little more tricky as you don’t want to lose your valuable content, but need to unpick any malware that may have been attached to it. This is a slow, painstaking process and there are very few shortcuts. Here are some useful links for resolving WordPress hacks, and helping to prevent them in the first place.
Be ready – one day your site will come under attack and you need to be ready to get things working again. This is a fact of being online in the 21st century and as we become dependent and totally connected through more prevalent and capable mobile (formerly edge) devices, we will see the number of attack vectors increase and threaten to black out more and more sites.