WordPress 4.7.2 Security Update
WordPress is a continually-innovating, monster-sized player in the modern web ecosphere. As such, it’s always a major deal when a rare high-severity security vulnerability is discovered in WordPress’ core code. On a network like ours, that can mean 400,000+ vulnerable installations.
On January 26, 2017, WordPress version 4.7.2 of WordPress was released. This update was primarily created to fix a high-severity vulnerability existing exclusively in versions 4.7.0 amd 4.7.1 due to the inclusion of the new REST API.
Without any public details on what the vulnerability was (a best practice to avoid widespread abuse), we had to work quickly to deploy WordPress updates across our network before the nature of the vulnerability became public and attackers started to target it.
Our automatic updates and strong security defenses take server management off your hands so you can focus on creating a great website.WordPress + DreamHost
WordPress, being forward-thinking, enables automatic updating of minor versions by default. WordPress sites that have AutoUpdate enabled will automatically be upgraded through its own “wp-cron.php” functionality, triggered with each page load. We went through each and every WordPress site on our network (over 750,000 of them!) and began to trigger these updates less than an hour after we were alerted to the nature of the problem.
The great news here is that automatic updates for security have been enabled on WordPress for years. Unless you specifically took steps to disable this functionality at some point in the past, your site was already equipped to grab and install the latest patch to fix this particular exploit. PHEW!
Details of the vulnerability in the new REST API were soon released by WordPress:
https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/
Shortly thereafter, public examples of how to exploit the vulnerability appeared:
https://www.exploit-db.com/exploits/41223/
Then the attack attempts began…
Here’s what we saw on our end:
We acted rapidly to add web application firewall (WAF) rules to block these attacks along with network firewall blocks against the IPs that we saw most frequently attempting to take advantage of this exploit. This meant that if your WordPress site was still stuck on one of the vulnerable versions (4.7.0 & 4.7.1) after the vulnerability became public and you had “Extra Web Security” enabled for your domain, the attack attempts were blocked.
Network firewall blocks of IP addresses stop these attempts from even reaching the WAF. Without network mitigations, we estimate that aggregate attempts to exploit this across DreamHost would be many multiples higher than shown in the above chart.
DreamHost and others are seeing this attack commonly being leveraged for Black Hat SEO purposes. Nefarious attackers are injecting links to their scummy websites in hope of an improved Google search ranking. By being associated (and linked from) with your own legitimate and respected website, this is a way for search engine spammers to game the system. We have not seen any cases where an attacker was able to add a backdoor shell and have only seen website defacements.
If by some chance you were targeted during the brief time period before your WordPress site was updated to 4.7.2 and had content inserted on your site that was placed there by nefarious na’er-do-wells, you can mitigate the vulnerability and restore your site to a pre-exploitation state by doing the following:
1. Upgrade to WordPress 4.7.2 (or higher if currently available).
2. Restore your database from a backup. DreamHost’s web panel makes this easy.. https://help.dreamhost.com/hc/en-us/articles/215100557-How-do-I-restore-my-database-in-the-panel–
Our own internal security team works tirelessly to monitor and track the latest exploit trends just like this one before they become widespread problems.
We would like to thank the WordPress Core Development Team for acting quickly and responsibly in getting an update out before the vulnerability was publicly disclosed and any attacks were found to be active in the wild.
This incident highlights the importance of having AutoUpdate enabled for your WordPress installation to ensure that the window of time between “exploit discovery” and “public release” remains as small as possible.
If you have any questions, be sure to contact our support team or tweet us @DreamHostCare on Twitter!
