WordPress “Hacked By …” cleanup. Did this happen to your business?
By: James Phillips King
Tags: Security, Digital Marketing, WordPress, Web Development, Website

It’s Sunday morning, 26th February, and I get a panicked call from a business owner.

They’d just noticed that their WordPress site had been hacked…

The result of the hack, at least at first glance, was a blog post defacement. The latest blog post title and body were replaced with “Hacked By …”.

After investigation, I established that this was likely the only change. However, I also noticed that the post had been changed by multiple, different attackers.

While it is trivial to rollback the post, I opted for starting afresh with a previous backup from before the incidents. I decided on this option because the site is rarely changed, so reverting to a backup a month old didn’t affect any content. In addition, it allowed me to be confident that the site was clean within minutes of getting the login details from the business.

From there I updated the site to the latest WordPress version and reset all keys and passwords to ensure that any leaked information could not be used to access the site again.

WordPress 4.7.0 and 4.7.1 are vulnerable.

After cleaning up a breach you need to establish how it occurred. Themes, plugins, WordPress itself, server software and password can all have vulnerabilities. It was important to find the likely culprit so that we can fix/mitigate the vulnerability.

In this case I suspected a vulnerability that I had read about a few weeks ago. A feature enabled in WordPress version 4.7.0, the WordPress REST API, was buggy, enabling unauthenticated modifications to any post or page of a WordPress site running version 4.7.0 and 4.7.1.

And it’s not hard to exploit! Within 48 hours after Sucuri’s announcement of their findings hackers were successfully modifying sites. In just a few days thousands of businesses were affected.

Within the disclosure article they explain the exploit and the cause, giving a specific request that could be used to change a post:

“an attacker could submit a request like _wp-json_wp_v2_posts/123?id=456ABC to change the post”

Sure enough, on inspection of the Apache log at the times of the defacement there are entries that look like:

POST _wp-json_wp_v2_posts/123 HTTP/1.1

Therefore confirming my suspicion that this vulnerability was the culprit. And since it was fixed in version 4.7.2, the site was now secure.

Securing WordPress sites into the future.

WordPress 4.7.2 was available for a while before the site was hacked. The problem was that the site hadn’t been updated.

The business owner told me that they log into the site about once a month to handle updates. However, this shouldn’t have caused an issue because since version 3.7 WordPress should automatically install security updates.

On inspection of the wp-config.php file I found the line:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

It disables all types of automatic update, a practice that is strongly discouraged and directly contributed to this issue.

WordPress was initially installed with their host’s “1-click WordPress installer”. I assume this line is one of their customisations.

The fix was simple, remove this line. Doing so automates installation of minor updates for WordPress, and enables critical security patches for themes and plugins.

I also enabled automatic plugin and theme updates .

I strongly encourage businesses to enable at least these critical updates because it is clear from the number of hacked sites that many do not. It is also possible that sites installed with custom scripts (such as the 1-click installers that some hosts offer) do not use the default settings. I recommend checking the automatic update settings if you’re unsure.

More than just defacement: remote code execution.

The incident I described above was limited to the defacement of one post. However, the damage can be even worse if an attacker can successfully run code on the server, essentially giving them full control of your site.

Sucuri have monitored attacks that attempt to exploit sites that use plugins like Insert PHP and Exec-PHP, which enable PHP code to be embedded directly in posts for customisation.

Like Sucuri state, plugins like those should not be used. Instead, PHP code should be limited to plugins and themes only.

However that doesn’t stop hundreds of thousands of sites from using these plugins and therefore being vulnerable to this new wave of attacks.

Don’t let this happen to your business: Update your site.

If you’re still running WordPress 4.7.0 or 4.7.1 you should update right now and investigate the possibility of security breaches (especially if you use a plugin like Insert PHP or Exec-PHP).

This issue highlights the importance of having automatic updates enabled. In addition, having backups of both files and databases, and an established plan for restarting from one of those backups, is imperative for businesses who need to stay online.