It has been nearly two weeks since the WordPress security team disclosed an unauthenticated privilege escalation vulnerability in a REST API endpoint in 4.7 and 4.7.1. The vulnerability was patched silently and disclosure was delayed for a week to give WordPress site owners a head start on updating to 4.7.2. Last week hundreds of thousands of vulnerable sites had already been defaced and the damage reports are still rolling in.
Over the weekend the attacks increased and WordPress security firms have seen more attempts blocked by their firewalls. Sucuri, the website security firm that reported the vulnerability to WordPress, was tracking the “Hacked by w4l3XzY3” campaign last week and estimated 66,000 defacements. That particular campaign has now passed 260,000 pages indexed by Google. It is one of nearly two dozen defacement campaigns targeting the vulnerability.
“During the past 24 hours we have seen an average growth in defaced pages per campaign of 44%,” Wordfence CEO Mark Maunder said on Friday. “The total number of defaced pages for all these campaigns, as indexed by Google has grown from 1,496,020 to 1,893,690. That is a 26% increase in total defaced pages in just 24 hours.”
Maunder referenced a Google Trends chart which he said demonstrates the success the defacement campaigns have had over the past week. The spike began on the day WordPress disclosed the vulnerability.
However, White Fir Design, another company that offers security services, disputes Wordfence’s claims that 1.8 million pages were hacked. The ~2 million pages figure is cited in reports from BBC, The Enquirer, Ars Technica, CIO.com, and other publications. White Fir Design contends that the hacked pages that have been indexed by Google are not an accurate representation.
Sucuri CTO Daniel Cid also does not fully agree with Wordfence’s assessment of the situation. After doing some research over the weekend, Sucuri estimates more than 50,000 sites hacked with 20-30 pages per site defaced. This would be roughly a million on the lower end of the estimate and ranges up to 1.5 million.
Sucuri is also starting to see more serious attempts on the REST API vulnerability in the form of remote code execution (RCE) attacks on sites using plugins that allow for PHP execution from within posts and pages. One such campaign attempts to inject a PHP include to add content from a compromised site and then inject a backdoor hidden in /wp-content/uploads.
“Defacements don’t offer economic returns, so that will likely die soon,” Cid said. “What will remain are attempts to execute commands (RCE) as it gives the attackers full control of a site – and offers multiple ways to monetize – and SPAM SEO / affiliate link / ad injections. We are starting to see them being attempted on a few sites, and that will likely be the direction this vulnerability will be misused in the coming days, weeks and possibly months.”
Hackers are targeting any sites that haven’t updated to 4.7.2 – there doesn’t seem to be any pattern among them. A quick look at the Google results for the most active campaigns shows that compromised sites include blogs, media, government, education, sports, medical, and technology websites.
Why the REST API is Enabled by Default
The WordPress REST API is enabled by default, as the plan is for more admin and plugin functionality to rely on the REST API in the future. After the recent attacks, several users commented on the vulnerability disclosure to ask why it is enabled by default.
“The security issue is in a feature I do not use on any of my sites (REST API) and yet still, this feature is first enabled by default and second since WordPress 4.7 you even need a plugin – which could introduce further security issues – to disable the feature?” one user (@helios2121) commented on the post. “Please rethink your approach to security. Make features that not everyone needs opt-in. Or at least give a way to opt out without requiring additional plugins.”
Morten Rand-Hendriksen opened a trac ticket to discuss disabling the REST API by default and only enabling it when the site admin requests it, or a theme or plugin is dependent on it.
Core Committer Sergey Biryukov confirmed that the plan is to introduce more core functionality that relies on REST API. “Turning off the REST API is like turning off admin-ajax.php — both will break your site,” Biryukov said.
Rand-Hendriksen asked why the content endpoints cannot be protected by default while allowing the REST API to be on by default for admin purposes. Another user asked why the Users endpoint isn’t protected by default (i.e. https://news.microsoft.com/wp-json/wp/v2/users or https://www.obama.org/wp-json/wp/v2/users), which “makes it easier than ever to get all the usernames” on any site using 4.7+.
“If you really want to disable the REST API on your site(s), this is our current recommendation: restrict it to authenticated users,” Core Committer James Nylen said. “However, we want to continue to increase adoption and usage of the REST API, and I expect that even this modification will break more and more WP functionality as time goes on, such as API-driven themes and embeds.”
Nylen recommends the Disable JSON API plugin for those who want to follow that recommendation on sites using WordPress 4.7+. The plugin currently has more than 10,000 active installs.
The WordPress security team worked diligently to mitigate the attacks by helping hosts and security firms put protections in place before the issue was made public. However, the full disclosure of the vulnerability was buried on the Make/Core blog, a site that is not widely read among regular WordPress site owners. The link to the disclosure was published as an addendum to the previous post on the WordPress news blog a week later.
“While I appreciate the responsible disclosure of this issue and the effort to resolve it, I hope you consider making future announcements via a new post on the WordPress News site, rather than just appending an update to a previous post,” user @johnrork commented on the official disclosure. “I am probably not the only one who could have avoided being compromised had this shown up as a new item in my RSS reader on Wednesday.”
Those who read the Make blogs had a head start on fixing their own sites and/or their clients’ sites. Those who depend on the WordPress news blog for information on security updates probably read the post when it was initially published and never returned to see the update a week later. An issue this severe warranted WordPress’ transparency in a new post on its news blog. This would have also automatically sent out a tweet to more than half a million followers on the official WordPress account and the Facebook account which has more than a million likes.
Fortunately, the number of vulnerable sites that also have plugins that could allow attackers to piggyback on this vulnerability is a much smaller number. Defaced sites are embarrassing but easy to fix. In most cases administrators need only update to 4.7.2 and roll back the defaced posts to the most recent revision. Most site owners have no idea how fast exploits begin to pop up after public disclosure, but this situation provided a gentle reminder of the importance of updating WordPress and the benefit of leaving automatic updates on.
Still wondering how so many websites are vulnerable when security updates should be automatically applied via auto-updates… AFAIK disabling auto-updates requires explicit action by the site’s owner/developer; Why would so many people disable this?