
Attacking WordPress - grflynn
http://www-personal.umich.edu/~markmont/awp/
======
zaroth
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)

~~~
coin
Presentation is utterly broken on an iPad. The back button is useless as it's
impossible to navigate anywhere.

~~~
zaroth
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!

------
meowface
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).

~~~
smacktoward
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®.

------
deckiedan
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)

~~~
techstrategist
That sounds sensible. I'd love to see any of the scripts you use (if they are
suitable for public consumption). Also running WP on nginx/php-fpm.

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

~~~
lmz
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?

~~~
Rapzid
[http://codex.wordpress.org/Hardening_WordPress#File_Permissi...](http://codex.wordpress.org/Hardening_WordPress#File_Permissions)

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.

------
scrapcode
Note: Do not press "n". For me, on Firefox, the site goes into an infinite
loop of pop-up windows.

~~~
room271
Seconded! Had to restart my browser :(

~~~
scrapcode
It ended up bringing out the pain points in Firefox's "feature" to recover
tabs... In this case I really didn't want that to happen!

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

~~~
singlow
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.

------
pc2g4d
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?

------
vezzy-fnord
I was expecting to see WPScan - it's had quite the refinements throughout the
years.

