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.