WordPress REST API Vulnerability Exploits Continue

photo credit: Code & Martini by Ivana Vasilj – cc license

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.

25 Comments


  1. 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?

    Report


    1. In reality, it is exactly the other way around. To have the feature working you need the webserver to be able to write to your code directories which is against web security good practices. It is also not very easy to set the correct directory permission if you are not familiar with the linux file permissions model which is way above the heads of the avarage wordpress user.

      And while defacements suck, most of those sites that have their file permissions set in a secure way, will be abale to avoid the most obvious remote executions attacks that are being attempted now.

      The right solution (if you are one of those that never heard how 4.7.1 broke sites, and therefor happy to install whatever software without checking it first) is to have the hosting companyhave some script of their own to do that which will run as a root user, eliminating all the permission complexities. I know siteground do that, probably other big hosters as well, but smaller ones might not even know that there is an issue that needs to be resolved.

      Report


      1. OK, I’ve been using Linux for 15 years so I didn’t even think of permissions as an issue here. Since you need to explicitly disable auto-updates I assumed people doing so were familiar with good permission setting too.

        Personally I’ve never had a single issue with auto-updates, even 4.7.1, so I’m pretty comfortable with letting them apply automatically. If anything goes wrong I’m usually able to step in within a few hours to fix whatever’s broken.

        Report


    2. Because in the past websites tend to crash on auto updates when plugins or themes where not ready to follow the changes WP made as they have and had a reputation of dropping functions/functionalities and add new ones instead without keeping the legacy code running. And nobody wants their site to go down. See what happened last year with one of the big changes in a Yoast Seo update. WP had a similar reputation. So developers started to turn off auto updates because of that.

      Report


  2. I know there are some installing apps for cpanel that either do by default like wptavern mentioned can’t remember which one it was. And other giving the option to turn auto updates off which maybe a lot of people do due to worrying it will break their site not sure.

    Would be interesting if there was a break down of what versions of WordPress are being hacked e.g. 4.7 to 4.6 and so on.

    Report


  3. Also, many organizations run under strict change management policies where auto updates are not allowed. Emergency patching can be done but this update, initially, didn’t appear to be an emergency patch situation.

    Report


  4. Obviously, auto updates is a feature not many are comfortable with. Thanks for sharing this…it’s really useful information.

    Report


  5. I am sorry to say that once again regardless of all publicity and probably more clients it gains for sucuri both wordpress and sucuri should not have brought the how to into the open. They should have kept their mouth shut and should have waited until they were absolutely sure that most websites have been updated. With bringing this into the open they put all these websites at risk and people have to restore their work. Any idea what economical costs this caused! I believe it is very stupid and irresponsible to disclose the how to hack into a website. Sucuri did this in august 2014 with the revslider hack and now they did it again. Whereas in august 2014 they never mentioned that the leak was already closed in februari of that year and that the hack only occured on websites that had not updated the plugin. It was just a win win situation for them then and now.

    Report


    1. This should 100% be in admin as a setting. “enable REST endpoints for authenticated users, only”. Why does it have to be any more difficult than that?

      Report


      1. Actually, it seems like you didn’t read the article, David. All it does is say how dependent WP will become on the REST API; some sites will still not need that – and should be allowed to turn it off.

        Report


  6. Here’s an idea. Why not implement a traffic-light system for wordpress updates? Red is critical, amber is urgent, green is “whenever”. That way, you can say “hey, this is really important” without initially disclosing the details of the exploit.

    Report


    1. People dont stop at traffic lights. Although i like the idea. But Sucuri should have kept their mouth shut on how to use this exploit. Its like little children wanted to be first with something.

      Report


  7. Glad I decided to stay at 4.6.x for my sites.

    Report


    1. You can say that out loud ! :-)

      Report


    2. Just to be clear, 4.7 fixed a number of security issues too so remaining on 4.6.x isn’t really keeping you ‘safe’.

      Report


      1. you are joking, right? lets compare the number of sites that run 4.6 that were hacked to the number of sites that run 4.7.

        The problem is actually that the opposite of what you say is true. There is simply no continuous improvement
        In the quality of core’s code. The bug causing this issue is a basic input sanitation bug, and I could dig into who submitted the code, and point the finger at him, but the truth is that the people that were supposed to code review the code and QA the code are actually more to blame than the poor guy/girl that actually wrote it. The fact that this kind of code made it to a release shows that there is no proper process to ensure that the next release will be “better” than the previous one.
        And all the people involved in the rest API are wordpress veterans so “it was a newbe mistake”, can not be a valid excuse (if it can ever be).

        Every release adds more unuseful bloat to the previous one, instead of fixing the structural problems of it. Why do you thing that a 4.8 release, which focus only on UI, will have a better security than 4.7?

        Report


      2. All the relevant fixes have been pushed back to 4.6.2 as well.

        Report


  8. Just want to say thank you for drawing attention to the fact that this was effectively hidden from a majority of site owners with the decision to not publish a new post on the News blog or tweet about it from the official account. It gives the impression that WP was trying not to publicize it which is really troubling and absolutely caused more damage.

    Report


  9. I got two emails last week from Drupal Security Advisories regarding two security vulnerabilities and updates marked Critical and Highly Critical. Does WordPress have this service to notify all WordPress.org users who opted in to receive security notification of critical update like this WP REST API?

    Report


    1. Hi Jeffrey, if WordPress do that, then they will loose the market share. They are more focused on Market share and less focused on taking responsibilities for the WordPress powered websites. And that is the reason we love Drupal. Clients do trust us because we are always ahead of time when we are with Drupal. With WordPress we have to be reactive and that is really risky, especially when you are working on high traffic, large content sites. We still work with WordPress when it’s flexibility helps but not if we see a potential threat considering the site objective. Eg. Simple Corporate site is good with WordPress but not a University Portal.

      Report


  10. At the end all these attacks will make whole internet a better place. It’s just a cleaning of outdated and unmanaged enviroments/websites. Also it pushes those who care, to build more secure sites and hosting enviroments.

    Report


    1. Agree with your latter point but you can’t really say that those exposed (unknowingly) that were on a 4.7 or 4.7.1 install should be considered “outdated and unmanaged”…

      Report

Comments are closed.