At the end of January, WordPress 4.7.2 was released to fix four security issues, three of which were disclosed at the time of the release. These included a SQL injection vulnerability in WP_Query, a cross-site scripting (XSS) vulnerability in the posts list table, and the Press This feature allowing users without permission to assign taxonomy terms. The fourth and most critical issue, an unauthenticated privilege escalation vulnerability in a REST API endpoint, was fixed silently and disclosed a week after the release.

Contributors on the release opted to delay disclosure in order to mitigate the potential for mass exploitation, given that any site running 4.7 or 4.7.1 is at risk. This allowed time for users to update manually and for automatic updates to roll out.

“We believe transparency is in the public’s best interest,” WordPress Core Security Team Lead Aaron Campbell said. “It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.”

WordPress worked with Sucuri, the company that discovered the issue, along with other WAF vendors and hosting companies to add protections before the vulnerability was publicly disclosed.

The vulnerability has been public for less than a week and is now being actively exploited. Thousands of WordPress sites have been defaced with messages like “Hacked by NG689Skw” or “Hacked by w4l3XzY3” or similar. Googling for information about these particular hacks returns thousands of other hacked sites in the results.

Sucuri founder and CTO Daniel Cid said his team saw exploits in the wild less than 24 hours after the disclosure. The attacks are primarily simple defacements so far.

“There are some good bad guys updating the post excerpt with the message: ‘Update WordPress or you will be hacked,’ which is kind weird,” Cid said. “But overall we’re seeing just simple defacement attempts, using modified versions of the exploit that was shared publicly.”

Multiple Campaigns Have Defaced Hundreds of Thousands of WordPress Sites

Sucuri is monitoring multiple defacement campaigns, each with varying degrees of success. The company published an update on the active attacks as well as the IP addresses they are originating from.

“We are currently tracking four different hacking (defacement) groups doing mass scans and exploits attempts across the internet,” Cid said. “We see the same IP addresses and defacers hitting almost every one of our honeypots and network.”

One defacement campaign Sucuri is tracking already has more than 68,000 pages indexed on Google. After perusing the WordPress.org forums, the problem seems to have a much larger reach than Sucuri’s network has initially detected. For example, “Hacked by NG689Skw” returns approximately 200K indexed results. “Hacked By SA3D HaCk3D” returns more than 100K results. There are multiple permutations of this defacement in play on WordPress websites across the web. Not all results that share this same campaign structure are guaranteed to be associated with this vulnerability, but the few listed above were recent posts on the WordPress.org forum from users who failed to update to 4.7.2 in time.

Cid said the vulnerability allows attackers to inject content into a post or page by default, but defacement is the easy first step, along with SEO spam. If a site has a plugin like Insert PHP or PHP Code Widget installed, the vulnerability can lead to remote code execution. These two plugins have more than 300K combined active installs and there are others that perform similar functions.

“The core of the issue is people not updating,” Cid said. “Even with auto and simple updates, people still do not update their sites.”

Needless to say, if you haven’t updated to 4.7.2 and your site is running 4.7.0 or 4.7.1, you are at risk for content injection. For most sites that have been defaced, the simplest solution is to update to the latest version of WordPress and rollback the defaced post(s) to a revision.

Like this:

Related

36 Comments

So a feature that sites didn’t need and will most likely never use, and by design can not be turned off makes a lot of damage…. who would have thought it could happen.

It is time that like it is expected from all plugin and theme authors, core will own its mistakes. (Not that the plugin authors do, ninja forms still provides its version two and three in the same plugin and it is probably only a matter of time until some bug will expose the users of the untested version two to hackers.)

Anyway, “decisions instead of options” assumes that the people that make the decisions make it based on the merits of the issues, and not based on social pressure and the need for “employee satisfaction”.

And yes I know that I am just ranting against the wind and nothing is going to change.

security is not a binary thing, it is more layered. I guess that you don’t put an alarm in your house, because you have windows and doors that should prevent people from getting in, or you do not use the apple tracking service for your iphone because you always keep the phone safe with you?

Without those plugin, a hacker can just mutilate the sites, with them he can take a full control of it. So I guess that you advocate that it is better to let hackers take full control, because security is hard and it is in your way while you want to do some quick hack instead of writing a proper code….

Having those plugin installed is probably like notifying putting big sign on your house that you have gold inside it, and you don’t believe in safes.

This brings up a concern some of us have voiced for a while now: shipping the REST API as an always-on feature to every WordPress site on the web introduces a new vector for exploits to sites that may never use the feature at all.

I have yet to see a compelling reason why the REST API is an always-on feature rather than opt-in based on use or admin choice. In my opinion, the API should be disabled by default and activated only when a theme or plugin dependent on the feature is activated or if the admin deliberately enables it to allow access from a 3rd party.

I would love to see arguments that prove me wrong, but like I said I have yet to see any.

Seems the point of the REST API being always on is to progressively make the Dashboard rely on it rather than internal data collection/processing. The REST API comes with a JavaScript/Backbone client library that will be quite useful to some devs (including myself) and I guess will be more and more used by the Dashboard in future releases.

Not sure that’s an argument, but at least it gives some kind of explanation.

Not very responsible I think given the magnitude of the security hole. Should have waited a month and there should have been a much bigger announcement about the need to update. I completely missed it.

No, Sucuri didn’t disclose anything hackers didn’t know by then. It was obvious from the short time between 4.7.1 and 4.7.2 that there was some major security problem that had to be fixed, and the official reasons just didn’t add up to something that requires a rushed release, so people that I know actually went to look at the actual code changes and saw that there was a change in the rest API. And this was just someone that was curious, true hacker probably saw the fault few hours after 4.7.2 was released and didn’t need any prof of concept from Sucuri.

A word to others surprised at the amount of sites defaced: This number from Google is very inaccurate. I doubt that this filters out multiple indexes of the same site and additionally KkK1337 and NG689Skw have done WP targeted hacks before. It’s fairly irresponsible to say that this is the result of this one attack.

That’s why we included a disclaimer regarding that: “Not all results that share this same campaign structure are guaranteed to be associated with this vulnerability, but the few listed above were recent posts on the WordPress.org forum from users who failed to update to 4.7.2 in time.” There are so many more than just the couple examples listed.

I’m pro-disclosure, but I’m very unhappy with how this was handled. For two reasons:

(1) Only about 5 days passed between release and disclosure? This is a massive vulnerability that takes less than a minute to exploit once you know what you’re doing. They knew once they disclosed they’d be inviting hackers into hundreds of thousands of sites. Surely they could’ve better emphasized the security concerns before disclosing, or waited more than a week.

(2) The announcement of the disclosure was made via an update to the bottom of the original 4.7.2 announcement post. Are you kidding? I didn’t see it. How would I? Why would I check the announcement post again? I guess I should’ve known enough to have been subscribed to the Make WordPress Core blog? (Unsubscribed to that a long time ago because of all the “Dev Chat Summary” cruft showing up in my email.) I would bet a vast swath of WPers get this type of information via the feed in their WP dashboards — that’s one of the most reliable ways to disseminate information to standalone WP sites — so by not posting about the disclosure specifically, we didn’t find out about it until days afterward (and for many, after it’s too late and a hack had taken place). Really disappointed.

When a minor release is announced (on the main blog, not core blog) I always take it seriously and update immediately. Waiting to see what is disclosed at a later point, after 5 days or 5 months, is not relevant for me.

I’m not claiming that minor updates shouldn’t be taken seriously. I’m saying that when disastrous vulnerabilities make their way into publicly-released code, they should not be disclosed via a tiny blog edit with no notification.

None of my clients were affected. They all, except one, auto updated within hours of the release. Because of my monitoring of all client sites, the one with an update problem, due to “disk full”, was fixed and then updated manually after 12 hours. I have a panel showing the version number and other info for all my client’s sites. Can’t run my business without that.

So, if you are a serious WordPress professional and site maintainer, you observe that all your client sites are immediately updated after a minor (security most) release. Did you turn off auto updates?

WP Tavern has previously had long discussions on the topic of automated updates being turned on as default.

Arguably it could be made clearer when automatic updates are turned off (due to the presence of a .git directory or other VCS files) – currently this just removes the “Future security updates will be applied automatically.” text on /update-core.php, rather than providing an explicit warning that they won’t, there or anywhere else.

I’m sure plenty of people are still unaware of this (or that there’s a filter to turn them back on).

Also, my honest opinion is the partial version numbers (4.7 vs 4.7.2) now displayed in readme.html are a step backwards. Besides the inevitable confusion this will create, it already seems to have produced false positive warnings from Google, for a couple of my sites at least), that and the plans to remove version info completely elsewhere.

Bad security issues in core are rare, but when you have the auto update on to get them automatically, it means that every plugin can override core files, and there is huge number of security issues with plugin.

When you do not let the server overwrite core file, the worst that can happen is that you will be defaced, but if overwrite is possible, your whole server might be owned and by the time you will discover it you will probably not have a “clean” backup (or more likely, you will not know which backup you can trust).

“There are some good bad guys updating the post excerpt with the message: ‘Update WordPress or you will be hacked,’ which is kind weird,” Cid said. “But overall we’re seeing just simple defacement attempts, using modified versions of the exploit that was shared publicly.”

Not so “weird” in reality. Take this example for example: Notifying someone that their website is hackable usually results in someone assuming you are the attacker/hacker. You should never contact a website owner directly – that will put them in a state of fear, shock and anger and they will bite you just like a wild animal would. It is much simpler and effective to automate a delivery system that gets the point across to the website owner without notifying them of who is trying to help them. Call it anti-hacking if you will. This is a theoretical example of course.