Attacking WordPress

I think it's a nice high level intro to exactly how easy it is to exploit an un-patched site. Obviously not ground breaking, but a nice intro nonetheless.

I think the key takeaway is, assume anything on or near your Wordpress is compromised. Because the attackers have IP maps of pretty much every Wordpress site, what versions, and what plugins they are running, so the moment an exploit is published their botnets will be attacking you within minutes. This already happened to Drupal and no reason to expect it's not happening to Wordpress as well.

The best defense is not storing anything which is not already public on the server, and a single-click restore feature which should be used liberally anytime a priv-escalating exploit is patched. (assume you were compromised, even in the absence of any logs indicating that you were)

>Remove any files, pages, posts, comments or processes added by the attacker. If in doubt as to whether you got everything, set up a new WordPress site from scratch and then restore your last known good backup into it.

>Change all passwords used by the site. Also change your hosting provider and database passwords.

All this after showing how easy it is to hide a backdoor.

If you have reason to believe your server is compromised, not only should you always wipe the web app and restore from backup (delete all of /var/www or equivalent and repopulate with your backup), you should wipe the server and reinstall the OS (or just request a new image to be spun up if it's a VPS/VM) too, unless you can 100% prove that the attacker didn't get root access, and you know everything they did, and know file permissions are set properly everywhere so www-data (or equivalent) couldn't read or write anything sensitive outside of the web server directories.

And even then, it saves you a lot of time, effort, and anxiety to just nuke and reimage by default.

This is yet another reason why frequent backups are extremely important. Just make sure you're restoring to a known good backup (hopefully you can confirm the time of compromise).

$Owner (owns directory, has rwx) $Owner-cgi (in group of $Owner, which has r-x, and only rwx in uploads) Everyone (can read files in upload, but cannot even read wp-config.php, or other similar files).

nginx runs as nobody, and so can read the static files, uploads, etc. But if nginx is hacked, it still can't read database configuration, etc.

Each $Owner-cgi user is what php-fpm (or HHVM, probably in the future) runs as. logged in users can upload new media content, but cannot install new plugins, edit php files, etc.

To upload new plugins, wordpress has a pretty cool 'use ftp' feature, which lets logged in users type in a ftp user on the server, which lets them install new plugins. The username/password they use is the $Owner one. The FTP daemon only allows localhost access, and the $Owner user doesn't have shell access.

nginx is set up to block a whole bunch of standard things (such as any request with wp-config in it...)

This setup automatically blocks most of the exploits that are around, and is pretty easy to use. It also means that even if a plugin does get exploited, there's very little that can be done, without knowing the FTP username & password (which is long, and random).

All of this enforced and configured by ansible. Setting up a new client site takes about 2 minutes. (Answer a few questions from my 'make a new client' script, and then run the ansible site.yml)

You can't update plugins via the admin with this setup, that is instead done with a deployment script.

I've deployed many WP sites with this setup and have never been hacked.

Oh fail2ban monitoring wp-login is also essential.

That said, seeing the ease with which WP can be hacked makes me once again question whether to switch to a simpler blog platform that poses a smaller attack surface. Anybody have experience with / recommendations of such systems?