7 ms·

Disclosure of Additional Security Fix in WordPress 4.7.2

35 points by tobltobs 10y ago

jgrahamc 10y ago
Because of the severity of the issue we decided to roll out WAF rules for all our customers (i.e. including those that don't get the WAF because they are on a free plan): https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/ https://blog.cloudflare.com/protecting-everyone-from-wordpre... Currently, we are seeing people probing this vulnerability.
- porker 10y ago
  Does anyone know of a set of WAF rules - free or commercial - that I can use on my server, rather than outsourcing to Sucuri or CloudFlare? I have used modsecurity before and found writing rules difficult, so happy to pay.
amq 10y ago
The title implies that WP did something wrong, but did they? As Sucuri notes: > We disclosed the vulnerability to the WordPress Security Team who handled it extremely well. They worked closely with us to coordinate the disclosure timeline and get as many hosts and security providers aware and patched before this became public. https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html https://blog.sucuri.net/2017/02/content-injection-vulnerabil...
- ceejayoz 10y ago
  The actions, at least as-described, sound entirely reasonable to me.
- deleted 10y ago
  [deleted]
- onion2k 10y ago
  The title implies that WP did something wrong, but did they? In my opinion the implication of what they did means people who don't host with Wordpress or Wordpress's partners will have to wait longer for security patches. That gives Wordpress and their partners a very clear business advantage - "host with us or be vulnerable to attack until we get around to releasing our patch publicly". That doesn't necessarily mean WP were in the wrong though. It's possible there simply wasn't a better approach - releasing a patch that doesn't fix the problem can be worse than waiting until you have a good fix, and you definitely can't disclose a problem until you have a strong fix. Put simply, disclosing vulnerabilities is hard.
  - fencepost 10y ago
    Is that "wait longer" referring to the difference between "over the weekend" for WAFs and "Monday" for WordPress hosts? Because I didn't get the impression that the companies that got advance notification were chosen based on being partners. They had to balance the question of getting as many installs as possible protected before doing the easy-to-analyze release, because probably within hours after the release there were going to be attacks starting to turn up. In the meantime, as long as they had feedback from the WAF vendors that the vulnerability wasn't being probed they had a pretty good idea that it wasn't widespread. The only real question about it that I was curious about as well is which firewall plugin developers they communicated with.
  - aaroncampbell 10y ago
    Put simply, disclosing vulnerabilities is hard. This is so true! To try to set the record straight, WordPress.org (the open source project) doesn't host and websites apart from our own (WordPress.org, WordCamp.org, BuddyPress.org, etc). So people can't host with us. Also, while we do have some recommended hosts that have helped the community as well as put a lot of effort into making their WordPress hosting really exceptional, they were not the only hosts we worked with on this (or even the majority). Additionally, the work with hosts and WAFs happened in parallel with the work on the patch. WordPress users are our priority and they exist at pretty much every host. The best way to secure them all is to get a patch out. Anything we can do to mitigate the risk between finding out and when that patch is ready, is really just a bonus :)
tyingq 10y ago
"The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all" Grr. Checked some sites, and the auto update hadn't yet upgraded to 4.7.2. Guess I get to go figure out why now.
- lsaferite 10y ago
  This I don't understand. Why run WP where the server has ownership and write access to the code? With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems. If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?
  - CJefferson 10y ago
    But in this case, an auto-updating install would be protected, while a non-updated version would now have the website over-written...
    - lsaferite 10y ago
      My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.
      - bigmanwalter 10y ago
        Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.
        lsaferite 10y ago
        Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices. You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.
testUser69 10y ago
Hopefully in 2050 our corporate overlords will still spend a week discussing how to patch vulnerabilities in our 3D printed food databases too.
bigmanwalter 10y ago
Dear HN hivemind, do you have any advice for me on how to keep my client's WordPress.org sites secure? A guide that you trust or maybe a good shared host that takes care of these things? Google just gives me a bunch of content spam, but I know that there's gotta be some best practices I can employ.
- hannob 10y ago
  1. You're using Wordpress, that's already good. It has autoupdates. You're unlikely to get hit by a vuln like this. 2. Don't disable autoupdates. 3. Avoid plugins and external themes. If you can stick to Wordpress Core. If you use plugins use as few as possible and only ones that are maintained regularly. Keep plugins and themes updated. 4. Don't disable autoupdates. Also, have I mentioned you shouldn't disable autoupdates?
  - bigmanwalter 10y ago
    What if my clients like their absurd selections of plugins and themes?
- mpol 10y ago
  What is a good thing is keeping on top of updates for WordPress Core, plugins and themes. You could decide to not upgrade when a new major version comes out, like 4.8.0, but wait till there is a 4.8.1. Often there is a rush to pack new features in a new release, and the first update often has quite a few security fixes. Also, be picky about which plugins and themes you use. And if you notice that one becomes unmaintained (no updates anymore), make a plan to switch to something else. /edit: Commercial themes are often overloaded with lots of functionality that you don't need. If you care about security, avoid them. There are also plugins like WordFence, which might be a good idea (I don't really know). Most things that are in there should really be handled serverside, like mod_security rules and firewall rules. This topic is about WAF rules, which are serverside done afaik. If you just use shared hosting and have no control over the server, using WordFence might be a good idea.
- trakout 10y ago
  Keep it updated, and don't use 3rd party plugins.
urbanj 10y ago
Mods, can you edit the headline please - editorialising
droopyEyelids 10y ago
flagged for editorializing the title
- grzm 10y ago
  No need to flag: just comment what the correct title should be, and perhaps contact the mods alerting them that it should be changed.
  - DrScump 10y ago
    Mods, when you do retitle, please add a quick "title changed from (x) to (y)" comment (most usually do) so we know when such complaints become obsolete.
edm0nd 10y ago
Good thing https://github.com/rastating/wordpress-exploit-framework https://github.com/rastating/wordpress-exploit-framework exists
danielcid 10y ago
We are seeing attacks in the wild for it already. Mostly defacement attempts at the moment. Marc, the researcher that found it, wrote the technical details here: https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html https://blog.sucuri.net/2017/02/content-injection-vulnerabil... thanks,

35 points by tobltobs 10y ago

Because of the severity of the issue we decided to roll out WAF rules for all our customers (i.e. including those that don't get the WAF because they are on a free plan): https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/ https://blog.cloudflare.com/protecting-everyone-from-wordpre... Currently, we are seeing people probing this vulnerability.

porker 10y ago
Does anyone know of a set of WAF rules - free or commercial - that I can use on my server, rather than outsourcing to Sucuri or CloudFlare? I have used modsecurity before and found writing rules difficult, so happy to pay.

amq 10y ago

The title implies that WP did something wrong, but did they? As Sucuri notes: > We disclosed the vulnerability to the WordPress Security Team who handled it extremely well. They worked closely with us to coordinate the disclosure timeline and get as many hosts and security providers aware and patched before this became public. https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html https://blog.sucuri.net/2017/02/content-injection-vulnerabil...

ceejayoz 10y ago
The actions, at least as-described, sound entirely reasonable to me.
deleted 10y ago
[deleted]
onion2k 10y ago
The title implies that WP did something wrong, but did they? In my opinion the implication of what they did means people who don't host with Wordpress or Wordpress's partners will have to wait longer for security patches. That gives Wordpress and their partners a very clear business advantage - "host with us or be vulnerable to attack until we get around to releasing our patch publicly". That doesn't necessarily mean WP were in the wrong though. It's possible there simply wasn't a better approach - releasing a patch that doesn't fix the problem can be worse than waiting until you have a good fix, and you definitely can't disclose a problem until you have a strong fix. Put simply, disclosing vulnerabilities is hard.
- fencepost 10y ago
  Is that "wait longer" referring to the difference between "over the weekend" for WAFs and "Monday" for WordPress hosts? Because I didn't get the impression that the companies that got advance notification were chosen based on being partners. They had to balance the question of getting as many installs as possible protected before doing the easy-to-analyze release, because probably within hours after the release there were going to be attacks starting to turn up. In the meantime, as long as they had feedback from the WAF vendors that the vulnerability wasn't being probed they had a pretty good idea that it wasn't widespread. The only real question about it that I was curious about as well is which firewall plugin developers they communicated with.
- aaroncampbell 10y ago
  Put simply, disclosing vulnerabilities is hard. This is so true! To try to set the record straight, WordPress.org (the open source project) doesn't host and websites apart from our own (WordPress.org, WordCamp.org, BuddyPress.org, etc). So people can't host with us. Also, while we do have some recommended hosts that have helped the community as well as put a lot of effort into making their WordPress hosting really exceptional, they were not the only hosts we worked with on this (or even the majority). Additionally, the work with hosts and WAFs happened in parallel with the work on the patch. WordPress users are our priority and they exist at pretty much every host. The best way to secure them all is to get a patch out. Anything we can do to mitigate the risk between finding out and when that patch is ready, is really just a bonus :)

tyingq 10y ago

"The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all" Grr. Checked some sites, and the auto update hadn't yet upgraded to 4.7.2. Guess I get to go figure out why now.

lsaferite 10y ago
This I don't understand. Why run WP where the server has ownership and write access to the code? With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems. If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?
- CJefferson 10y ago
  But in this case, an auto-updating install would be protected, while a non-updated version would now have the website over-written...
  - lsaferite 10y ago
    My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.
    - bigmanwalter 10y ago
      Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.
      - lsaferite 10y ago
        Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices. You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.

testUser69 10y ago

Hopefully in 2050 our corporate overlords will still spend a week discussing how to patch vulnerabilities in our 3D printed food databases too.

bigmanwalter 10y ago

Dear HN hivemind, do you have any advice for me on how to keep my client's WordPress.org sites secure? A guide that you trust or maybe a good shared host that takes care of these things? Google just gives me a bunch of content spam, but I know that there's gotta be some best practices I can employ.

hannob 10y ago
1. You're using Wordpress, that's already good. It has autoupdates. You're unlikely to get hit by a vuln like this. 2. Don't disable autoupdates. 3. Avoid plugins and external themes. If you can stick to Wordpress Core. If you use plugins use as few as possible and only ones that are maintained regularly. Keep plugins and themes updated. 4. Don't disable autoupdates. Also, have I mentioned you shouldn't disable autoupdates?
- bigmanwalter 10y ago
  What if my clients like their absurd selections of plugins and themes?
mpol 10y ago
What is a good thing is keeping on top of updates for WordPress Core, plugins and themes. You could decide to not upgrade when a new major version comes out, like 4.8.0, but wait till there is a 4.8.1. Often there is a rush to pack new features in a new release, and the first update often has quite a few security fixes. Also, be picky about which plugins and themes you use. And if you notice that one becomes unmaintained (no updates anymore), make a plan to switch to something else. /edit: Commercial themes are often overloaded with lots of functionality that you don't need. If you care about security, avoid them. There are also plugins like WordFence, which might be a good idea (I don't really know). Most things that are in there should really be handled serverside, like mod_security rules and firewall rules. This topic is about WAF rules, which are serverside done afaik. If you just use shared hosting and have no control over the server, using WordFence might be a good idea.
trakout 10y ago
Keep it updated, and don't use 3rd party plugins.

urbanj 10y ago

Mods, can you edit the headline please - editorialising

droopyEyelids 10y ago

flagged for editorializing the title

grzm 10y ago
No need to flag: just comment what the correct title should be, and perhaps contact the mods alerting them that it should be changed.
- DrScump 10y ago
  Mods, when you do retitle, please add a quick "title changed from (x) to (y)" comment (most usually do) so we know when such complaints become obsolete.

edm0nd 10y ago

Good thing https://github.com/rastating/wordpress-exploit-framework https://github.com/rastating/wordpress-exploit-framework exists

danielcid 10y ago

We are seeing attacks in the wild for it already. Mostly defacement attempts at the moment. Marc, the researcher that found it, wrote the technical details here: https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html https://blog.sucuri.net/2017/02/content-injection-vulnerabil... thanks,