Using Task Scheduler To Open Outlook At Predefined Intervals, Using PowerShell
December 14, 2016
2017 Web Development Conference Opportunities
January 31, 2017

/Delete-all-comments Hack – Lessons Learned

What Happened

On December 19, 2016 one of my (to this point largely unused) WordPress multsite networks was comprised, via a plugin vulnerability as described at http://blog.nintechnet.com/arbitrary-file-upload-vulnerability-in-wordpress-delete-all-comments-plugin/.  Thankfully the only two live sites on the network were student run, so they weren’t greatly missed given that the hack occurred over holiday break when classes weren’t in session. Part of the reason that the plugin was even installed initially was because the network went unused for a few days/weeks, so it amassed thousands of spam comments that needed to be deleted quickly.  Nonetheless the breach was a reminder that this sort of thing can happen at any point, including to another network I manage that is much more heavily used.

In any case, unfortunately no major WordPress security plugin could have prevented the exploit when it occurred: https://www.pluginvulnerabilities.com/tag/delete-all-comments/ – the only sure way to have avoided the hack would have been to not have the plugin installed (it was irrelevant that the plugin had been deactivated well before the exploit occurred).  Before the hack occurred, I felt like I was doing a reasonable job of securing this network:

  • I was running WordPress 4.7 at the time (the latest version).  All plugins were also up-to-date.
  • I had been using WordFence (to serve as a firewall)
  • I was using All-in-One WP Security (to enforce security rules, largely via htaccess modifications). I had most every security option enabled that I possibly could
  • I was utilizing eID logins universally throughout site, forcing all of those logins behind SSL
  • I had been enforcing a whitelist such that only only-campus or VPN traffic could log into the back-end of my network
  • I also keep daily backups

Once in, the hacker was able to send out hundreds of thousands of spam e-mails leveraging our SMTP server, and they were able to introduce many dozens of backdoors into the system as well that had to be located/removed.

Lessons Learned

  • It doesn’t really matter how hard you work to secure your site if you install a plugin that has a vulnerability.  As https://codex.wordpress.org/Hardening_WordPress notes, plugins/themes are the #1 attack vector of WordPress.  I unknowingly introduced a Trojan Horse into my network via a plugin, and it was exploited even though the plugin was deactivated
  • Not only deactivate, but delete every non-essential WordPress plugin
  • The UNIX team now enforces SMTP rate limiting on my multisite networks.  If you know your sites never need to send out more than X e-mails per hour, then why allow a hacker to send out tens of thousands of e-mails per hour?
  • Leverage WPScan and their vulnerabilities database.  In my case, I decided to install a Vulnerability Alerts plugin which notifies me whenever one of my plugins/themes has been identified as vulnerable.  I also confirmed that this plugin identified the /delete-all-comments vulnerability.
  • Identify a good malware scanner that checks not only the core, but ideally every file in the system.  I ended up trying a few different scanning tools, but “WordFence” and “Anti-Malware Security and Brute-Force Firewall” seemed to be the most thorough (ie, they both expectedly took at least an hour to perform a full scan of every file in the system.  Other scanners may have been faster, but they weren’t thorough)
  • I knew this inherently before, but the hack underscored the fact that you can’t trust that a security plugin is going to keep you safe.  Case in point, WordFence decided to only patch the paid version of their plugin when they were informed of the vulnerability, but not the free version, which I was using (https://www.pluginvulnerabilities.com/tag/wordfence).  I subsequently decided to stop using WordFence in favor of another firewall tool, partly for this reason but also for performance reasons.
  • This may not have prevented this attack, but it couldn’t hurt to introduce rules in your robots.txt file to block rule-abiding search engine bots from crawling certain areas of your site (wp-admin, as well as the plugins, themes and a few other areas the general public wouldn’t need access to):
#
User-agent: *
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /wp-content/themes/
Disallow: */trackback/
Disallow: */feed/
Disallow: /*/feed/rss/$
Disallow: /category/*

Helpful Resources