Exciting work is being done with regards to the WordPress auto-update system that allows the WordPress team to sign each update.
That signature can be verified by each WordPress installation to guarantee you’re installing the _actual _WordPress update and not something from a compromised server.
Compromising the WordPress Update Infrastructure
This work is being lead by security researcher Scott Arciszewski from Paragon Initiative, a long-time voice in the PHP security community. He’s been warning about the potential dangers of the WordPress update infrastructure for a very long time.
Scott and I discussed it in the SysCast podcast about Application Security too.
Since WordPress 3.7, support has been added to auto-update WordPress installations in case critical vulnerabilities are discovered. I praised them for that – I really love that feature. It requires 0 effort from the website maintainer.
But that obviously poses a threat, as Scott explains:
Currently, if an attacker can compromise api.wordpress.org, they can issue a fake WordPress update and gain access to every WordPress install on the Internet that has automatic updating enabled. We’re two minutes to midnight here (we were one minute to midnight before the Wordfence team found that vulnerability).
Given WordPress’s ubiquity, an attacker with control of 27% of websites on the Internet is a grave threat to the security of the rest of the Internet. I don’t know how much infrastructure could withstand that level of DDoS.
Scott has already published several security articles, with Guide to Automatic Security Updates For PHP Developers arguably being the most important one for anyone designing and creating a CMS.
Just about every CMS, from Drupal to WordPress to Joomla, uses a weak update mechanisme: if an attacker manages to take control over the update server(s), there’s no additional proof they need to have in order to issue new updates. This poses a real threat to the stability of the web..
For WordPress, a federated authentication model is proposed.
It consists of 3 key areas, as Scott explains:
- Notaries (WordPress blogs or other services that opt in to hosting/verifying the updates) will mirror a Merkle tree which contains (with timestamps and signatures):
-– Any new public keys
-– Any public key revocations
-– Cryptographic hashes of any core/extension updates
WordPress blogs will have a pool of notaries they trust explicitly. […]
When an update is received from the server, after checking the signature against the WP core’s public key, they will poll at least one trusted Notary [..]. The Notary will verify that the update exists and matches the checksum on file, and respond with a signed message containing:
-– The challenge nonce
-– The response timestamp
-– Whether or not the update was valid
This will be useful in the event that the WP.org’s signing key is ever compromised by a sophisticated adversary: If they attempt to issue a silent, targeted update to a machine of interest, they cannot do so reliably [..].
This way, in order to compromise the update system, you need to trick the notaries too to accept the false update. It’s no longer merely dependent on the update system itself, but uses a set of peers to validate each of those updates.
Show Me The Money Code
Because WordPress supports PHP 5.2.4 and higher (this is an entirely different security threat to WordPress, but let’s ignore it for now), a pure PHP implementation of libsodium is needed since the PHP binary extensions aren’t supported that far back. The pecl/libsodium extension requires at least PHP 5.4 or higher.
Here’s hoping the patches get accepted and can be used soon, as I’m pretty sure there are a lot of parties interested in getting access to the WordPress update infrastructure.