The best part about this presentation, aside from the scrollable slides, is that it didn't break the back button. :-)
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)
Single tap to advance, but it gets stuck on Slide 9 because the scroll view. I agree meets the definition of broken, but... at least the back button works!
I'm very surprised by the unwise compromise remediation advice:
>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).
Because of the popularity of WordPress at the low end of the CMS market, administrators of WordPress sites are very frequently not the same people who admin the servers those sites run on; think shared hosting, for instance. (And in the case of scenarios like shared hosting, the WordPress admin may not have any administrative control over the server whatsover.)
So it tells those people how to do what they can do -- secure their WordPress installation. Protecting the integrity of the server/hosting environment itself is Somebody Else's Problem®.
Additionally, it might be useful to install a rudimentary file integrity tool tool (eg. tripwire) as part of the backup process. This way you can tell if (a) new files are added; and (b) if the hashes of any files changed unexpectedly.
I have my clients wordpress sites hosted as follows:
$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)
I always give the webserver read only access to the file system, except the uploads directory, and then prevent the webserver from being able to execute php inside the uploads directory.
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.
This should be a more common configuration and it would be nice if web apps themselves promoted using different OS identities for sensitive parts. W^X and privilege separation are widely used in daemons, why not in web apps?
People just don't RTFM. It has been mentioned in Wordpress's hardening information for years and years aoubt having the web server process running as a separate user than the file owners along with the proper permissions.
The biggest update to Wordpress that always been missing is an ability to customize directory structure to make it harder for scripts to poll for plugins, themes, versions and whatnots.
My wordpress installs all have a custom directory structure. Core WP files are in /wp and a separate directory contains the plugins, themes and uploads folders. You can configure WP to do this, and Roots Bedrock does this for you. Not really a security feature, though. But it is nice to not have your plugins and themes in a subdirectory of WP since bedrock updates plugins and wp via composer.
This was a great presentation. It gave me some practical things to change to increase the security of my WP install.
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?
> Out-of-date and improperly configured software being at-risk to canned exploits is nothing new
Yeah, but this is not the case here. The software isn't out of date or improperly configured, the software works as intended,it's just full of exploits that will never be patched. To be fair wordpress itself is secure. His blog was hacked because he used a third party plugin that had an known but unpatched exploit.
Here's 100 WordPress exploits, found from the exploit search on metasploit.com - looks a lot like it's all plugins and themes (I haven't checked exhaustively):
which gives attackers huge attack surfaces because of WP's popularity. I'm guessing less than 5% of WP users probably sandbox and properly test their plugins before using them too.
Just by not using WP, you effectively reduce the attack surface of your site or blog immensely. Just self hosting your blog or site would be significantly safer than using WP.
Full disclosure: I've never liked WP from the start and probably never will for a myriad of reasons.
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)