Up to a quarter of all websites on the internet could have been attacked through a since-patched vulnerability that allowed WordPress' core update server to be compromised.

The since-shuttered remote code execution flaw was found in a php webhook within api.wordpress.org that allows developers to supply a hashing algorithm of their choice to verify code updates are legitimate.

Matt Barry, lead developer of WordPress security outfit WordFence, found attackers could supply their own extremely weak hashing algorithm as part of that verification process, allowing a shared secret key to be brute-forced over the course of a couple of hours.

The rate of guessing attempts would be small enough to fly under the radar of WordPress' security systems.

Attackers that used the exploit could then send URLs to the WordPress update servers that would be accepted and pushed out to all WordPress sites. Web-watching service W3techs.com reckons those sites represent 27.1 per cent of the entire world wide web.

"By compromising api.wordpress.org, an attacker could conceivably compromise more than a quarter of the websites worldwide in one stroke," Barry says.

"We analysed [WordPress] code and found a vulnerability that could allow an attacker to execute their own code on api.wordpress.org and gain access to it.

"Compromising this [update] server could allow an attacker to supply their own URL to download and install software to WordPress websites, automatically."

WordPress update flow. Image: WordFence.

Attackers could go further; once a backdoored or malicious update was pushed out, they could disable the default auto updates preventing WordPress from fixing compromised websites.

Barry says WordPress fails to use signature verification to check the updates to be installed and instead trusts all URLs and packages supplied by api.wordpress.org.

WordPress' hashing verification process can be weakened allowing attackers to use a POST parameter passed as is and unescaped to shell_exec, granting remote code execution and compromise of the api.wordpress.org update server.

Barry selected the weak adler32 hashing algorithm to dramatically reduce the number of possible hashes required to crunch from 4.3 billion (2^32) to between 100,000 and 400,000.

"This is a far more manageable number of guesses that we would need to send to the webhook on api.wordpress.org which could be made over the course of a few hours," Barry says. "Once the webhook allows the request, the attack executes a shell command on api.wordpress.org which gives us access to the underlying operating system and api.wordpress.org is compromised."

Barry reported the bug to WordPress creator Automattic on 2 September and a fix was delivered five days later.

Yet he still considers api.wordpress.org to be the single point of failure for the millions of WordPress sites that rely on the server for updates.

He says Automattic has not responded to his requests to discuss the failure point and the need to provide an authentication mechanism for updates.

Barry is not the only security boffin concerned with the absent control; discussions this week on the OpenWall security mailing list described theoritical attacks very similar to that the researcher today disclosed.

But the idea dates back at least three years ago when one user proposed that updates should be signed, an idea that has to date been ignored. ®