
WordPress Security: Seven Ways I Could Hack Into Your WordPress Site - mmaunder
http://markmaunder.com/2011/12/08/wordpress-security-ways-hack-wordpress-site/
======
patio11
Some more advice for HN users of WP:

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.

~~~
ryan-allen
I think point #1 is very important. I do this also:

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

~~~
dbarlett
Stay away from Page.ly unless you like unannounced maintenance during business
hours. I've also seen frequent outages they blame on Firehost networking and
SAN.

~~~
ryan-allen
Ah, well that's unfortunate. Have you got any other managed providers you can
recommend?

~~~
dbarlett
My client decided to move to a VPS, but <http://wpengine.com/> looked
promising.

------
VonLipwig
When I was doing client work, I would sort out a hacked Wordpress blog at
least once a fortnight.

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.

~~~
bad_user

        One of the big selling points of Wordpress is
        that there is a plugin for anything
    

Most plugins and themes available are shitty.

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.

~~~
rkudeshi
Jekyll is great, but far from accessible for novice or even intermediate
users.

Out of curiosity, link to your new blog?

------
comex
The interesting thing about WordPress is that it's one of the few cases where
an alternative is vastly more secure while providing similar functionality -
namely, any blog software that exports a set of static HTML files.

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.

~~~
betageek
I don't think static site generators are suitable for most WordPress uses -
the key feature is to allow non-technical users to easily add content and
publish immediately which WP does very well. Teaching them Markdown (or
similar) and some CLI is not an option.

------
dotBen
As a WordPress fanatic, I just want to point out that - other than keeping
your WordPress Core, Themes and Plugins up to date (which should be obvious by
now) - none of the vectors described are actually WordPress related.

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?

~~~
patio11
There are particular ways in which Wordpress exacerbates this situation. For
example, let's say one of your $10 an hour freelance authors uses an insecure
password. What happens? Content defacement? Much of the time, the answer is
_arbitrary code execution_ , because Wordpress has had _copious_ local-to-
Wordpress privilege escalation vulnerabilities and, once they're admin, they
can upload arbitrary PHP to your web server straight through the site.

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.

~~~
dotBen
I'm not aware of any unpatched vectors to perform arbitrary code execution in
WordPress Core. Sure perhaps via a dodgy plugin (and then ok you could run a
SQL query directly to change the privilege level of a given user).

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! ;)

------
kemayo
Topically enough, I just found out[1] the importance of the themes point. A
wordpress theme that had been installed on my wife's blog (not even the one
she was actually using) included a file for thumbnail generation[2] which had
a security hole found in it in August.

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-...](http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-
wordpress-themes/)

~~~
ricardobeat
TimThumb is widely used not only in WP. Plugins are way more dangerous, themes
don't usually include external libraries or complex code/services.

------
ricardobeat
3, 4, 6 and 7 amount to "I'll guess/brute-force your passwords".

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

