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.
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.
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.
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?
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.
Wherever possible, outsource. wordpress.com if you can deal with their limited selection of themes and plugins, any number of third-party outsourcers whose bread and butter is WordPress if you need your own theming.
(I maintain three WP myself by hand, but that's me being a control addict.)
WP's core security is vastly better these days. So instead you'll fall prey to a cruddy plugin or theme ... especially the latter, being PHP written by designers. (Nothing against good designers, but design thinking is not security thinking.)
A really useful shortcut: put /wp-admin/ behind Apache basic auth. This stops most doorknob-rattling automated 'sploits in their tracks. (Main barrier to doing this in practice is that nontechnical editorial people tend to get confused by two layers of password.)
I operate a semi-well-known website that has been running Wordpress for over 11 years, and it's been hacked and attacked relentlessly since the early days. On multiple occasions the attackers have managed to get their "dashboards" onto the server to insert spam links and use my server in a botnet.
I keep my Wordpress and plugins up-to-date, but they still kept finding ways in. What finally worked for me was to write a simple front-loader to replace the Wordpress front-loader. It has a whitelist of allowed $_POST fields, a blacklist for $_POST content, and it deletes anything in $_FILES unless the user is on a whitelisted IP. This has kept the site safe for several years now so far.
Mine is an extreme case, but maybe this approach will be helpful to other extreme cases.
I would recommend using a wholly hosted solution, such as wpengine or wordpress.com. WP has a history of serious vulnerabilities and running a few instances yourself is not worth the operational costs.
"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.
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?
[+] [-] jgrahamc|9 years ago|reply
Currently, we are seeing people probing this vulnerability.
[+] [-] porker|9 years ago|reply
I have used modsecurity before and found writing rules difficult, so happy to pay.
[+] [-] amq|9 years ago|reply
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-vulnerabil...
[+] [-] onion2k|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ceejayoz|9 years ago|reply
[+] [-] danielcid|9 years ago|reply
Marc, the researcher that found it, wrote the technical details here:
https://blog.sucuri.net/2017/02/content-injection-vulnerabil...
thanks,
[+] [-] bigmanwalter|9 years ago|reply
Google just gives me a bunch of content spam, but I know that there's gotta be some best practices I can employ.
[+] [-] hannob|9 years ago|reply
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?
[+] [-] mpol|9 years ago|reply
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.
[+] [-] davidgerard|9 years ago|reply
(I maintain three WP myself by hand, but that's me being a control addict.)
WP's core security is vastly better these days. So instead you'll fall prey to a cruddy plugin or theme ... especially the latter, being PHP written by designers. (Nothing against good designers, but design thinking is not security thinking.)
A really useful shortcut: put /wp-admin/ behind Apache basic auth. This stops most doorknob-rattling automated 'sploits in their tracks. (Main barrier to doing this in practice is that nontechnical editorial people tend to get confused by two layers of password.)
[+] [-] DamnInteresting|9 years ago|reply
I keep my Wordpress and plugins up-to-date, but they still kept finding ways in. What finally worked for me was to write a simple front-loader to replace the Wordpress front-loader. It has a whitelist of allowed $_POST fields, a blacklist for $_POST content, and it deletes anything in $_FILES unless the user is on a whitelisted IP. This has kept the site safe for several years now so far.
Mine is an extreme case, but maybe this approach will be helpful to other extreme cases.
[+] [-] CaveTech|9 years ago|reply
[+] [-] fencepost|9 years ago|reply
[+] [-] trakout|9 years ago|reply
[+] [-] tyingq|9 years ago|reply
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|9 years ago|reply
If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?
[+] [-] edm0nd|9 years ago|reply
[+] [-] urbanj|9 years ago|reply
[+] [-] droopyEyelids|9 years ago|reply
[+] [-] grzm|9 years ago|reply
[+] [-] testUser69|9 years ago|reply