36 Comments

  1. mark k.

    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.

    Report

  2. mark k.

    …. and on a related note, why does those php shortcode and widgets are in the repository at all? They are a big security hole just waiting to be abused, and @otto knows that so wtf?

    Report

    • Bill Murray

      Those plugins are useful to some people that require the ability to run custom PHP code. It’s not the plugin’s fault that the API was exploited.

      Report

      • mark k.

        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.

        Report

  3. Morten Rand-Hendriksen

    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.

    Report

  4. Anh Tran

    This bug has effected some of my websites. I couldn’t believe that how hackers can exploit the bug so fast, especially when REST API is a new thing in the WordPress core.

    Hopefully this kind of bugs won’t happen in the future. It’s too dangerous to see that happen on clients’ websites.

    Report

    • Bjørn Johansen

      Sucuri disclosed the details a week after WP 4.7.2 was out. it was so detailed it was very easy to create an exploit without doing much research on your own.

      Report

      • Andreas Nurbo

        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.

        Report

      • mark k.

        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.

        Report

  5. CP

    Hacked by NG689Skw is now at 233,000 Google hits. Way to go.

    Report

  6. Jeffrey

    I have two sites still not updated (I though I have enabled auto update, but somehow it didn’t work), and fortunately they were not hacked before I manually updated them today.

    Considering there are so many sites running WP, the impact is going to be huge. Is there a place that site owners can sign up for security notification?

    Report

  7. Pat Hartl

    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.

    Report

    • sarah

      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.

      Report

  8. Rick Rottman

    Anyone know how often stuff like this happens with platforms like Squarespace or Wix?

    Report

  9. Jonah Brown

    Drupal has API but it is usually turned on when a development team enables it. *hint, hint

    Report

  10. Morten Rand-Hendriksen

    I filed a ticket to disable REST API by default, making it opt-in rather than always-on: https://core.trac.wordpress.org/ticket/39806#ticket

    Report

  11. Mike

    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.

    Report

    • Knut Sparhell

      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.

      Report

      • Mike

        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.

        Report

  12. Jonas Sandström

    This crap affected two of my clients site. It’s things like this that makes me start questioning WordPress as a serious CMS.

    Report

    • Knut Sparhell

      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.

      Report

      • Jonas Sandström

        The two sites hade auto update turned off due to legacy code from my clients previous developer that I hadn’t had the time fix.
        What kind of panel is that, please tell me.

        Report

      • William

        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.

        Report

      • mark k.

        running with auto update on is actually less secure than off.

        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).

        Report

  13. Edward Alexander

    “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.

    Report

  14. Claire Brotherton

    I’ve just noticed that the iThemes Security plugin has a setting to restrict access to the REST API data. https://ithemes.com/security/wordpress-rest-api-restrict-access/

    Not sure if it would have prevented this hack, but interesting nonetheless.

    Report

Comments are closed.

%d bloggers like this: