Since 2013, WordPress has been updating itself, which is a good thing.
Unless, that is, somebody hacks the update server.
And that’s exactly where the WordPress security outfit WordFence found a vulnerability that could have led to the megahacking of 27% of the entire WWW.
The remote code execution flaw, since fixed, was found in an open-source PHP webhook within the update server, api.wordpress.org.
The webhook lets WordPress developers sync their code to the wordpress.org code repository, enabling them to use GitHub as their main source code repository, WordFence explained:
When they commit a change to GitHub it will reach out and hit a URL on api.wordpress.org which then triggers a process on api.wordpress.org that brings down the latest code that was just added to GitHub.
The problem with this particular webhook was that it let developers supply their own hashing algorithm to verify that code updates are legitimate. It didn’t matter whether it was GitHub or an attacker hitting the webhook: either could feed in the hashing algorithm used to verify the message authenticity.
Given a weak enough hashing algorithm, attackers could brute-force attack the webhook with a number of guesses that wouldn’t trigger WordPress’s security systems.
WordFence managed to come up with an algorithm that reduced the amount of guesses from 400,000 to only 100,000 guesses, with randomly generated keys, at the hash value of the shared secret key. That guessing would only take a few hours.
With the door successfully battered down, attackers could then send URLs to the WordPress update servers, which would then push them out to all WordPress sites.
And that’s a hell of a lot of sites. WordPress is the most popular Content Management System (CMS) on the web, by far: according to Web-watching service W3techs.com, it’s running about 27% of all websites.
Matt Barry, the lead WordFence developer who discovered the bug, disclosed it to the WordPress team via HackerOne, and was awarded a bounty for his report:
By compromising api.wordpress.org, an attacker could conceivably compromise more than a quarter of the websites worldwide in one stroke.
None of this is an argument against auto-updates, mind you. They’re vital, given that people aren’t good at updating their CMS. Even if they do update them, they likely don’t update them quickly enough when a problem occurs.
A few years ago, vulnerability researchers at EnableSecurity took a look at the 40,000 most popular sites running WordPress and found that at least 30,823 of them were running versions with known vulnerabilities.
From that, they concluded that 73.2% of the most popular WordPress installations were open to vulnerabilities that could be detected using free automated tools.
As Mark Stockley noted when he wrote up that bit of discomfort, the first rule of WordPress security is to always run the latest version of WordPress.
Updating quickly is important because attacks against serious CMS vulnerabilities can spread within hours, and there’s obviously nothing the crooks like better than a trick they can use over and over and over to compromise millions and millions of sites.
That’s been well-illustrated by problems that have hit other, similar CMSes. Joomla and Drupal, for example, are numbers two and three behind WordPress, respectively. They’re big, though at 3.3% and 2.2%, they’re nowhere near as big as WordPress.
Two years ago, we saw a major SQL injection bug in Drupal that triggered attacks within a mere 3 hours of the patch appearing. The Drupal Security team warned users who hadn’t patched within 7 hours that they’d likely been compromised.
A few weeks ago, we saw another serious CMS threat come in for Joomla sites: This one allowed anyone to register themselves as an admin user on any affected Joomla site. Web security company Sucuri said that if you hadn’t patched within three days, you’d likely been compromised.
Ironically, users’ failure to keep their sites up to date with the latest software would actually have meant the WordPress bug wouldn’t have affected all of the 27% of sites running the CMS; rather, it would have hit only those running a version of WordPress released since October 2013 who had not switched off automatic security updates.
Does procrastination and turning off auto security updates pay? Nope. This is the megahack that almost happened but thankfully didn’t.
The chances of getting another near-miss that you could have avoided by not updating WordPress?
Too miniscule to justify ignoring the first rule of WordPress, which is always worth repeating: always run the most recent version of WordPress!
Leave a Reply