Category Archives: wordpress

Going static

A few years ago, I started this blog for two reasons. First, I wanted a place to share thoughts, ideas, tools, and research on web security. After seven posts, I consider it a success.

Second, I saw a few WordPress sites being hacked under “my watch”. This would typically translate to unauthorized changes in the form of defacement or including malware to promote its dissemination.

All the forensic analyses led to the same conclusion: the attack could be tracked to either an outdated WordPress core or an outdated plugin. This got me thinking about how hard it would be to keep a WordPress installation up-to-date and safe from being hacked. 

And that was the second reason: I wanted to experience first-hand the pain other site owners were having and hopefully reach some practical advice that would make them safer and I could sleep better.

So my first blog post, Hardening WordPress, was the start of that experience.

And today, eight years later, is the end of that experience. I give it to you that the experience effectively ended a few years ago, and in the last few years, this blog was abandoned and only used as a firing range for my current challenge (Probely).

I am proud to say the blog was never hacked, I think… At least, I never saw any unauthorized content or change, it was never reported as malicious, and the downtimes were only caused by me being cheap and using a t2.nano AWS instance.

Doing an analysis after all this time is hard, but let me try:

– my initial hardening had a significant impact, and I’m pretty sure most installations are not hardened at this level. Protecting the login and admin pages with strong Basic Auth credentials protected me against brute-force attacks. More importantly, my passwords were 30 chars long, randomly generated by a password manager using a large character space.

– having a minimal set of plugins and themes reduced my attack surface: I only installed a stats plugin, Akismet, to handle spam in the comments and the Sucuri Security Scanner to check for changes.

– having a plugin checking for filesystem changes and applying security best practices also helped.

– having 1 click updates and automatic updates was super cool and helped me stay up-to-date. But I remember it was a pain to set up if you wanted to minimize the amount of access WordPress had to the filesystem. I had WordPress SSHing to itself through localhost, with a dedicated account, with limited permissions. This prevented the code from changing the filesystem, but it was still able to run a specific command to update it. That broke frequently, so I later reverted to whatever setup WordPress recommended.

Today it auto-updates itself, updates the plugins and themes, and I get a friendly email saying what happened.

I know my setup was not as realistic as other installations running businesses on top of their installation, so I would often install some plugins my network used. And it was a nightmare because I could no longer update WordPress immediately, as some plugins would get disabled. If I were lucky, the plugin would get an update in a few days or weeks. Some never got updated.

So that was my main conclusion after a few months: it was trivial to let WordPress become out-of-date because you didn’t set up auto-update. Either inadvertently or on purpose to avoid breaking something. Or you could have set up auto-update, but it was trivial for the installation process to break with the slightest change. 

And if you don’t update immediately, you will likely not update in the following months.

Another issue was the dependence on no longer (or poorly) maintained plugins. Here the options were to stop using the plugin or modify it to fix the vulnerabilities. The former was the choice when the plugin had a secondary role, like providing access stats. The latter was reserved for plugins that supported the business, like e-commerce, and if the team had developers capable of modifying the plugin. Unfortunately, this would easily take weeks or months.

After a while, I no longer really care about WordPress :)

I must be honest; for the last 3 or 4 years, my biggest challenge was handling MySQL with 512 MB of RAM and being able to upgrade to newer releases of Linux with just 8 GB of disk. When I got tired of that and upgraded the machine resources, I decided that it made no sense to keep supporting this cost.

So more expensive and less fun, and it made me convert this to a static version. And it couldn’t be easier:

  • Install a plugin like Simply Static
  • Generate a zip with all the content
  • Commit it to a GitHub Pages repository
  • Update Cloudflare CNAMES to point to GitHub, fine-tune the TLS, redirects, and DNS to work with HTTPS, with and without www, and you are done.
  • Take down the WordPress VM

So that is the end of this WordPress experiment. I will keep it offline just in case I want to continue to post or do some experiments. But most likely not.

Hardening WordPress

I think it makes sense that the very first post on my brand new WordPress blog would be about hardening WordPress itself. This makes even more sense if you consider it took me more time to harden this blog than to write this post.

For the installation just follow the official documentation found here to which I just want to make one remark about the database password strength:

GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname" IDENTIFIED BY "password";

Use a long password here, something like sK8ytB8mR5PtxqqTmCEYThEUJS5J6D which is 30 chars long. You won’t need to type this password often so there is no need to use a memorable one.
To be honest, a weak password here wouldn’t be that bad since it is unlikely that you server will fall because of this…unless you expose it beyond 127.0.0.1.

For the hardening, start here. There is some smalltalk but there are also some good advices regarding a few topics:

  • updates
  • file permissions
  • wp-admin
  • wp-includes
  • security plugins

updates
Keeping your installation up to date is paramount to ensure proper security. Before version 3.7 updates really sucked because the easiest way to (automatically) update was to have all files writable by the webserver process, so basically any malicious code executed by the webserver would be able to overwrite any file from our installation. The alternative was more secure but harder, so people wouldn’t update.
In the latest versions there is some magic that let you have automatic updates without the need to have files writable by the webserver. I think there is more than one way to achieve this: I went for the SSH one.
I followed this tutorial. In addition to the 5 defines added to the wp-config.php file, I also added define('FS_METHOD', 'ssh2');.
Since we are adding a new SSH user and we don’t want to increase your attack surface, disable password authentication for SSH at /etc/ssh/sshd_config with PasswordAuthentication no. Well…you should always disable password authentication for SSH.

file permissions
The important thing here is to prevent the webserver from writing files. There are some exceptions, as you might want to allow functionality such as image upload (so I can haz pretty potatoes pic).
You can have all files with owner and group wp-user, everything with 644 (files) or 755 (diretories).
The exception is wp-content/uploads that must be writable by the group (775) and have the group www-data set. You don’t need to allow webserver writing for the others since updates and installations are done through SSH and run with wp-user.

wp-admin
/wp-admin is a prime target for attackers because that is where you login to administrate your blog with your admin username and your weak password :)
Leaving /wp-admin world accessible exposes you to two problems: credential bruteforce/reuse/theft and direct access to files that may have all sort of vulnerabilities.
The most practical way to protect you from these is require some sort of authentication, say basic authentication. With nginx you just need to add this to your virtual host

location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /path/to/your/htpasswd;
}

and define the username and password. Please use a strong password here and also for your /wp-admin accounts.

EDIT
Also protect the /wp-login.php since it is used to login to edit the blog.
I include the snippet below to demonstrate the care you must take with nginx locations while configuring the rules described in this blog. Without going into details, prefix matching has precedence over regexp matching and nested locations with regex must have only regex inside.
location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/htpasswd;
}

location ~ .php$ {
location ~* /wp-login.php {
auth_basic "Restricted login";
auth_basic_user_file /etc/nginx/htpasswd;
}

location ~* wp-config.php {
deny all;
}

security plugins
Having many plugins installed is asking for trouble since many have vulnerabilities and don’t even get fixed. So, going against the usual recommendation of not installing plugins, install the Sucuri Security – Auditing, Malware Scanner and Hardening plugin.
After installing, you get a Sucuri Security button on your dashboard side menu that lets you access the plugin dashboard
Sucuri Security menu

Some of the features are paid, but you get a few nice things for free. In the hardening tab you can verify if have the proper secure configurations, however some only work if you are using Apache. More specifically, “Protect uploads directory”, “Restrict wp-content access” and “Restrict wp-includes access” will remain red under nginx even if properly configured, because the plugin expects Apache specific configuration.
In the Settings tab you have another interesting feature: the scanner. The plugin can scan your wordpress installation for changes and notify you by email, like an HIDS. Go through the Settings tabs and activate/deactivate options as you please.

Additionally to the 5 previous topics, I recommend following this extra 2:

Delete themes
Regarding themes…you just use one so delete those you don’t use, as well as the pre-installed useless plugin Hello Dolly.

Limit PHP execution
Direct access to PHP files laying around in your installation are known to cause problem, so disable PHP execution wherever you can. If using nginx add the configuration below to your virtual host. For Apache just use the Sucuri plugin or use Google.

location ~* wp-config.php {
deny all;
}

location ~* wp-content/(.*).php$ {
deny all;
}

location ~* wp-includes/(.*).php$ {
deny all;
}

location ~* wp-includes/uploads/sucuri$ {
deny all;
}

And finally…HTTPS
I don’ need extra motivation to make my blog available only by HTTPS but you if you are thinking twice, just remember Google favors HTTPS sites in the search results and you can get certificates for free from StartSSL, for instance.
Configuring HTTPS for WordPress is just like doing it for any another virtual host. Just remember a few things:

  • change your site from http://example.com to https://example.com at Settings->General->WordPress Address and Site Address
  • force a 301 redirect from HTTP to HTTPS
  • send a HSTS header to ensure you are always under HTTPS
  • disable all SSL versions and enable only TLS
  • enable strong ciphers such as ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH
  • enable server cipher preference

Then, go to SSL Labs and test your configuration.

If you are paranoid, you can continue hardening your WordPress, webserver, PHP, and OS forever, but you have to balance that against the time you have available.

So..I guess I have an WordPress blog. Lets see how long it holds without being hacked…