The Stack Archive

Why don’t we just update our WordPress websites when 142 million domains are at risk?

Tue 8 Sep 2015

WordPress, Joomla and Drupal logos

Not for the first time this year, or even necessarily this week, warnings emerge that hackers have found and exploited another vulnerability in the WordPress content management system. This time – again, it’s far from the first time – the attack vector uses script injection and fresh vulnerabilities in the Adobe ecosystem of web-based rich media plugins, namely Flash and Acrobat Reader.

Heimdal Security’s report states that since WordPress represents 24.3% of all websites and 58.7% of all websites which use a content management system, 142 million websites are currently at risk. This week’s alarm regards a compromised WordPress CMS directing users through ‘halfway-house’ domains that eventually lead to an attempt to install the ransomware Trojan Neutrino, a derivative of the Teslacrypt malware template.

Tech-savvy consumers used to responding to these vulnerability alerts in software they use by installing a ‘fix’ or patched update inevitably fill up the comments sections of various popular posts which discuss these CMS exploits. Long before anyone breaches Godwin’s Law, someone else will post a comment to the effect: ‘Just update your WordPress. Simples.’

A search for ‘disable updates’ at the WordPress plugin site yields a scary thirty-four pages

The fact that it isn’t simple for publishers which use customised content management systems such as WordPress, Joomla and Drupal, is the very reason why a ‘zero-day’ CMS vulnerability is far more valuable to hackers and other cyber-malfeasants than a mere software or plugin exploit – the window of opportunity is inevitably far longer, because in many CMS installations the smallest update can not just break the appearance of the website, but even stop it functioning or open up other vulnerabilities for hackers to exploit.

Worse, the highly-frequented sites which use a popular CMS not only represent the widest and most attractive possible market to cybercriminals, but are almost certain to be among the last to be able to respond to critical vulnerability alerts.

Why is it so?

‘Urgency’ redefined in the open source programming community

Anyone with experience of programming a CMS from scratch knows how the initial brief determines the destiny of the entire project, and this applies equally to a ‘mainstream’ CMS. Stripped of residual diplomacy, the questions programmers really ask at the start are: ‘Do you want it cheap, quick or good? Pick two’. ‘How many users are you expecting?’. ‘Do you want it modular?’. To the last, the reply is usually ‘yes’ – until the commissioner hears how much extra time and expense will be involved in creating flexible and truly modular code, which usually reverses the initial decision.

To the second question, no-one contemplating the creation of an unknown content management system out of whole cloth is likely to answer ‘More than 200 million’. WordPress (and its peers) would look very different if its future success had been augured at inception. For instance it wouldn’t demand a valid email for each WordPress installation user and then attempt to broadcast it in plain text on the author page, gabble out a (possibly out-dated) version number that would inevitably be of interest to no-one but hackers, and provide discoverable and easily guessed user login names by default.

You have to go a fair way downstream of the development communities to find anyone who is getting paid at all.

Since the top three content management systems are open source, there are no financial imperatives from the community end to fix core problems which impact highly commercialised or high-volume sites. Critical core fixes can have such disastrous consequences for the very (often free or open source) plugins and lateral add-ons that made the CMS popular in the first place that fixes are approached with a rational circumspection; one that defines good programming approaches but defies good security practice as it might manifest in a completely commercial software ecostructure.

The open source community will fix ‘the problem’ when the fix is solid, in its opinion, and not any earlier than that. And the commercial entities who may have invested thousands – or hundreds of thousands – in building a huge and impressive edifice over the Lego village of a basic WordPress install…they’ll apply that patch when they’re sure it isn’t going to take their site offline indefinitely or otherwise put them out of business. In the meantime, yes – that window, with whatever stopgap measures might be applied, is often left open for longer than one would want.

Rebooting or forking a popular content management system project

If hackers are attacking vectors close enough to the original core functionality of a CMS, it might also seem ‘simple’ to the casual commenter to address the underlying problem rather than attempt to plaster over it, and this seems a reasonable response.

But the problem of re-architecting a complete and mature software project such as WordPress or Joomla is so immense as to, in effect, constitute scrapping the existing project and starting again. It also obliges the often-weary, unpaid developers who have contributed so much to the success of the CMS to likewise abandon years of dedicated volunteer work in order to set out the same project aims from scratch under the ‘new and improved’ APIs and frameworks. You have to go a fair way downstream of the development communities to find anyone who is getting paid at all.

If so many large commercial concerns have so much invested in a product that emanates from a community which cannot be controlled by market imperatives, has no-one considered, for instance, forking WordPress into a commercial branch?

Yes, they have, but ultimately the power of the crowd won over the devastating potential expense of maintaining a dedicated effort to preserve and evolve the codebase in a commercial context. The yuppies, it seems, are stuck with the hippies for the long haul.

The problem of retrofitting good security on a CMS

There are a myriad of plugins which WordPress users (and, as in the rest of this article, this applies to other CMSes) can download and install to address new or old security concerns or other perceived shortcomings of the Codex. You can disable the default comments system if you’re going to use Disqus instead, or bolt on two-factor authentication and other local security features.

But if you’re not keen to find that a ‘critical fix’ has auto-applied itself and destroyed your website or theme in the process, you can disable automatic updates as well as WordPress core updates and theme updates. In fact a search for ‘disable updates’ at the WordPress plugin site yields a scary thirty-four pages.

However every plugin that fixes an undesirable CMS default consequently becomes a new potential point of vulnerability for CMS attackers, with many adding to a site’s load time as well (since the top three content management systems load every single active plugin on every single page loaded, even if that page does not use the plugin).

But this is not an ‘anti-update’ post. We’d all press that red ‘update all’ button if we could be sure we’d still have a viable site at the end of it – or even a job. But the truth is that the content management systems (some with budgets ranging between £70-90k) I’ve worked on in several publishing houses were all built out upon these same quirky open source foundations, like a city built over a village built over a swamp.

So we can’t just ‘press the button’. First we have to call the £70p/h developer and get a quote for compatibility testing on the staging server. If the update should prove to interfere with other functionality on the site, we’ll need a higher quote and to await a development slot; and the beta testing; and the eventual transfer slot; and the ‘post-transfer patch-ups’ that the beta tests missed.

So, sadly, it isn’t ‘simples’.

Anyone with any experience of developing a content management system from scratch is likely to be a little horrified taking a trek round a default WordPress install, noting some of the quaint legacy features and the trusting way that they are web-facing by default; to consider the almost-vanished ‘home-brewed’ web into which the major CMS systems wandered those years ago, as fledgeling projects, and note how much of that idealism and optimism is left behind in the current code, now that it’s out in the big bad city.


feature security
Send us a correction about this article Send us a news tip