Is Your WordPress Site Vulnerable?

WordPress is a very popular and free open source Content Management System (CMS) based on PHP and MySQL. As per W3Techs Web Technology Surveys, 58.5% of all the websites having low traffic uses WordPress as their Content Management System (CMS).

Recently, a major vulnerability was discovered which could have resulted in a mass compromise of a majority of WordPress websites (27.2% of the entire WWW). This vulnerability was reported by Wordfence which regularly looks for security vulnerabilities in the third party plugins and themes that are used by WordPress community including examining WordPress core and related wordpress.org systems.

Every WordPress website makes a request to the WordPress API Servers (api.wordpress.org) once an hour to check for the plugin, theme or WordPress core updates. By default, the auto-update in WordPress is enabled and following are the type of automatic background updates available:
Core updates
Plugin updates
Theme updates
Translation file updates

If this server is compromised, hackers can supply their own URL to download and install software to WordPress websites automatically and thus providing a way to mass-compromise through the auto-update mechanism. Furthermore, as WordPress do not provide any signature verification of the software being installed and will always trust any URL or any package supplied by api.wordpress.org, there is always a high possibility of this type of compromise.

The vulnerability discovered was a remote code execution (RCE) vulnerability and it was found in an open-source PHP Webhook which Github uses to contact api.wordpress.org. The main purpose of this webhook is to allow WordPress core developers to sync their codes to http://wordpress.org SVN repository and use Github as their source code repository. When a change is committed to Github, it reaches out and contacts this webhook to activate a process of pulling down the latest codes added to Github. Now the main issue with this webhook was that it allows developers to supply their own hashing algorithm to verify that the code updates are authorized. There are a lot of non-cryptographically secure hashing algorithms like crc32, adler32 which are just fast checksums, generates a 32-bit hash, specially designed for catching data transmission errors only and do not provide any cryptographic security at all. Out of these, when adler32 (which is weak for short messages) is used in combination with PHP’s hash_hmac function, it severely limits the number of possible hashes and creates significant non-uniformity in hash space. This ultimately results in the creation of a weak hashing algorithm which can be tested with randomly generated keys to reducing the number of guesses and requests. Also, the hackers can use it as a brute force attack on the webhook without even triggering the WordPress’s security systems.

Although this vulnerability was quickly fixed by the WordPress team, api.wordpress.org still remains the single point of failure (SPOF) when distributing WordPress core, plugins, and theme updates and there can be more vulnerabilities which are yet to be discovered.

So, now the important question is “Should we completely disable the automatic update until a more secure system is deployed by WordPress?”. This is not at all recommended and the default auto-update feature should be always kept enabled because if there is a new severe vulnerability in WordPress core or a theme or plugin, you will benefit from an auto-update fix which will be pushed out of WordPress.