WordPress Security: Seven Ways I Could Hack Into Your WordPress Site
markmaunder.com
markmaunder.com
1) chmod /var/www/whatever and all subdirectories such that the web server user can read but not write to them. If you need to do uploads or add a plugin, you can do it over SSH. Allowing someone to execute arbitrary code from your website is just asking for pain.
2) Many (but not all!) exploits start in wp-admin. I make mine inaccessible over the public Internet, enforced ny Nginx before any PHP gets the chance to execute. (Options: only accessible over VPN, only accessible through proxy you control, only accessible with a client certificate, etc.)
3) Routine DB/code backups. I'd keep wp-content in a git repo. Add a plugin? Have to add it through repo. Code changes other than through git? Smack yourself for setting permissions wrong, then roll back to a known good version from the repo. Weird links on blog pages? Roll back DB to known good version.
4) Should go without saying, but every blog gets it's own user and own DB, and that user only gets sufficient privileges to manipulate the blog DB.
5) Write a shell script to do an automatic "upgrade all blogs to latest version of WP" since you'll be doing this a lot. If this were totally risk-free I'd put it on an hourly cron job.
* All code is owned by a 'code' user, and all files by default are user and group read/write. * The www-data user (who runs the web server) can only write to wp-content/uploads and where ever else the plugins are required to write to * The places www-data can write to have .htaccess files that turn off execution of PHP scripts (so the app itself cannot upload code and run it, if there is a zero day exploit like the timthumb.php).
What this causes though is a bunch of plugins to complain they cannot work due to not enough access, and WP upgrades can't be done through the wp-admin, this tends to upset end users a bit, so I agree #5 is important.
I have a deploy user who is in the code group so I can manage our automated deploys.
Also, by default wp-admin doesn't have any login restrictions so people can brute force it (I think). It's really important to install something like the wp-recapcha plugin so people can't brute force your logins. This is especially important as end users who are creating accounts often choose poor passwords.
I like #2, I don't do this, though I think I'm going to have to!
Generally it comes down to typical system admin best practices. You're running a codebase you didn't write yourself, you have no idea what it's going to do.
EDIT: These permission things are not typically doable if you're running your blog on shared hosting. So shared hosting is generally not particulary safe. I'd recommend anyone without a dedicated sysadmin to use something like http://page.ly/, which is managed by smart guys.
The only thing the users had apparently done wrong was not updated their installation. It was because of this that I started to move clients away from Wordpress. The trouble is that a lot of non-tech clients will not touch their admin panel very often and I have found the older generation don't like the word update. It suggests to them "may break or change theme so I can't find stuff."
I find the idea that - probably - the worlds most popular website platform can frequently ship with security issues demoralising. If you look at all the people involved with Wordpress you would have thought that by now they would have squeezed the issues out of WP and learnt enough to ensure they stay squashed in the future. Maybe I expect a bit too much here.
One of the big selling points of Wordpress is that there is a plugin for anything. However.. how many of these have security issues? It is even worse as non-tech users just assume that as the plugin can be accessed from the their admin panel it must be safe.
It is for these reasons that I do not use Wordpress at all. I think it is an alright platform, not keen on the theming aspect but it is OK. However its incredible popularity makes it the target of hackers and spammers. When working with non-tech clients who may or may not update their website, Wordpress is liability more than anything else.
One of the big selling points of Wordpress is
that there is a plugin for anything
I just started a new blog and had to decide: Blogger, Wordpress or Jekyll. I chose Jekyll and I have all the functionality I could need from Wordpress plugins:
The URLs are SEO-friendly by default, Disqus is great for comments, Google Analytics, FeedBurner for RSS stats + email newsletter and I can change the design in any way I want, without limits and without having to spend quality time with Wordpress' codebase.
It's also super fast too, since the content is static and the hosting is free on GitHub Pages. I don't need to care about backing up my articles either, since I always have a full local copy and GitHub is GitHub. I also don't need to care about upgrades.
Out of curiosity, link to your new blog?
It's not perfect, since any of the listed breakin methods not directly related to a WordPress vulnerability is still available, and you have to make sure your control panel is actually secured the way you think it is, and if you use a service like Disqus for comments you theoretically gain nothing, since you're just outsourcing your security to someone else's webapp running arbitrary JavaScript in your domain...
But in practice, using static publishing is an excellent compromise: PHP webapps are probably one of the least secure categories of software in existence, especially compared to relatively secure OS services; it's usually easier to update the OS, and all updates come from one place; and the same solution also happens to be vastly better performing if your site is under load.
Can you list some? I think http://www.movabletype.org/ qualifies.
If you have an insecure password, are running exploitable services/software on your server or your host's support is social engineer-able then you're screwed regardless of what you're running.
So can we end this meme, which this post is somewhat fueling, that WordPress is insecure?
Or let's say you allow anybody to sign up and comment on your blog. What's the downside risk, pesky comments? Nope, arbitrary code execution, because anonymous one-off commenters get an admin area and it has had copious local privilege vulnerabilities to turn them into real admins and then it is off to the races.
Then there is the XMLRPC library. Wordpress ships with it on by default. What's the risk of leaving it on? Say it with me, arbitrary code execution, because...
And PHP encourages you to do includes, including (when an edge case gets missed) inclusions of remote files (!), which puts you at risk of...
I mean, I love Wordpress. Never point it at someone you don't want to kill, always treat it like it is loaded, and keep it in a locked case, and you're mostly pretty much safe.
XMLRPC ships in an 'off' state in WordPress, and has done for some time now.
You need a copy of Dr dotBen's "How I learned to stop worrying and love the WordPress", published by WP Engine! ;)
WordPress Core has so many eyeballs looking through the code, and some great full-time engineers working on it, that's it's actually very secure.
WordPress insecurities mainly occur when you add in badly written plugins - but that's not the fault of WordPress.
While I don't want to verge off-topic, that's actually the root cause of most WordPress-related vectors, and so it's sad that the original post didn't really reflect on that more (other than "keep the plugin up to date")
WordPress has exactly the same problems, and while the pace of security flaws in WordPress has surely slowed, what security researcher believes it has come close to stopping?
I stand by this comment I wrote almost two years ago:
http://news.ycombinator.com/item?id=1328261
Incidentally, "the security of WordPress plugins isn't the fault of Wordpress" is a dodge, because the severity of WordPress plugin flaws is a consequence of the fact that all WordPress plugins are just PHP programs with the same access as e.g. the code that handles site administration.
I recommend that people who care about security avoid WordPress, but if you don't want to do that, there are plenty of things you can do to mitigate your exposure. Yelling about whether that exposure exists at all is not one of the things I would recommend.
Other than two vectors that encompass all possible WordPress vulnerabilities except for 0days, none of the vectors are actually WordPress related?
If you want to evaluate WordPress's (or any webapp's) security, the important question is how often critical security updates have to be released - although, ironically, the more such updates there are, the more likely anyone who cares about security is to have a system to promptly apply them, having lots of them still means the webapp is less secure, and that 0days are more likely to be floating around somewhere.
(Since I don't use WordPress, I have no idea whether this is actually the case - I'm only pointing out that your argument is not the right way to establish its security.)
I just noticed that my second link goes to the same website as this article. :)
[1]: http://davidlynch.org/blog/2011/12/vulnerable/
[2]: http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-...
1, 2 and 5 amount to "I'll find a (generic) security issue in your software".
So it boils down to
- keep your software up to date - use safe passwords