Critical vulnerabilities pose a serious threat to Joomla sites

Joomla

Joomla, the world’s second most popular web content management system (CMS), has been under sustained attack for several days, thanks to a nasty pair of vulnerabilities disclosed last week.

Security announcements 20161001 (CVE-2016-8870) and 20161002 (CVE-2016-8869) describe how flaws in Joomla’s user registration code could allow an attacker to “register on a site when registration has been disabled” and then “register … with elevated privileges”.

If the significance of those two statements hasn’t entirely sunk in let me make it plain: taken together, the vulnerabilities can be used to unlock any site running Joomla, anywhere on the internet, with little more than a polite request detailing what you’d like to be called and how much power you want.

And there are a millions of vulnerable Joomla sites out there.

The Joomla vulnerabilities were caused by “Incorrect use of unfiltered data” and “Inadequate checks”, explanations that read like a potted summary of the last 20 years of web vulnerabilities.

All versions of Joomla from 3.4.4 to 3.6.3 are affected. Anyone still running an unpatched version of the CMS should upgrade to version 3.6.4 without delay and then scour their system for signs of compromise.

The 3.6.4 update simply removes the troubled code entirely, and fixes a third, related High Priority vulnerability, 20161003 (CVE-2016-9081) in the process.

There’s been such an upsurge in attacks since the vulnerabilities were disclosed that web security company Sucuri is suggesting that site owners assume that their sites are already compromised:

… because of the sharp increase [in attacks], it’s our belief that any Joomla! site that has not been updated is most likely already compromised.

The message is reminiscent of a warning issued in 2014 after a similarly critical vulnerability was discovered in Drupal, another hugely popular web CMS.

SA-CORE-2014-005 revealed that Drupal was vulnerable to a simple SQL injection attack that could grant an attacker total control over a compromised server.

Automated attacks against Dupal sites started within hours of the patch being released, leaving site owners with the narrowest of windows for deploying patches.

The Drupal Security team themselves reckoned that window was no wider than seven hours:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

If you were asleep when the initial email alert about the patch came in, too bad…

The success of popular CMSs such as Wordpress, Drupal and Joomla makes them hugely appealing targets – a single vulnerability can give criminals the opportunity to attack millions of targets from anywhere with one exploit.

Remotely exploitable vulnerabilities as serious as the ones found in Joomla last week are thankfully rare but with the web so neatly subdivided into vast CMS monocultures, a remote exploit can sweep through them like a fire through a parched forest.

And the threat posed by hacked sites reaches far beyond the individuals who own, operate and use them.

Compromised sites and servers can be corralled into botnets and used to distribute malware, send billions of spam emails or conduct devastating DDoS attacks.

The current state of countermeasures – sending emails or push updates and hoping site operators get them, read them, understand them and respond within a few hours – looks hopelessly inadequate by comparison.

Modern CMS software is successful in part because of the power it puts into the hands of non-technical users. Making those same users the linchpin of our collective security just makes no sense.

As we’ve said on Naked Security many times before, it doesn’t matter when a patch becomes available –  it’s when it’s applied that counts. That’s why I believe there’s simply no option for Drupal and Joomla but to follow the lead shown by WordPress and deploy automatic security updates by default.