The Global WordPress Hacking Campaign Explained

Last Monday many webmasters woke up to an uphill start to their week: over last weekend (February 4-5), a global scale WordPress hacking campaign was launched against virtually every website running on WordPress. If you consider that WordPress runs approximately 27% of the indexed web, that's a lot of people having headaches in one single day. Needless to say, it's not something you want to deal with in general, whether your sites got hacked or not. Let alone on a Monday morning.

What happened?

To give you some context, this hacking campaign consisted of exploiting a REST API vulnerability in WordPress (accidentally introduced in December alongside its latest major release) to silently overwrite articles by injecting propaganda messages with the ultimate aim of getting the content indexed by Google. The damage this time was more widespread but somehow less devastating than the average WordPress hack, since few individual articles were defaced rather than having the sites seriously compromised. The hack was deliberately made to act as quietly as possible so that the changes could go unnoticed until google indexed them. Apparently it worked very well (unfortunately) and  you can see the extent of the damage for yourself:


A sample result set of the damage caused by the WordPress defacement

How did this happen?

If you are wondering what made this mayhem possible, we need to go back to December 2016, when WordPress 4.7.0 was released. This major release packed a new set of features, including the REST API Content Endpoints. As usual after every major release of the CMS, a minor release was published just over a month later to address the known issues and security concerns. Fast forward two weeks and another minor version is released: WordPress 4.7.2. As you can see, this is listed purely as "security release", a.k.a emergency release. It's not uncommon, but it's generally a sign of bad things to come. If you take a look at the detailed release notes, you can see that the vulnerability is mentioned and there is also a link that leads to a more detailed explanation of the issue. Needless to say, the malevolent part of the hacking community struck gold and immediately started brewing methods to exploit the vulnerability. Starting less than 48 hours after the disclosure of the vulnerability, the number of public exploits attempts began to escalate exponentially and more and more puzzled help requests started appearing all over the message boards. Since the very moment the information was made publicly available,  the internet-wide probing and exploit attempts were deemed possible and the campaign began.

What went wrong?

This time, the good faith of the WordPress development team arguably backfired on the community. To be fair to the WP development team, the exploit was announced the same day the fix was released, and anybody that patched their own site(s) as soon as possible was safe from the exploit. But we all know that response times on maintenance tasks are often put on the long finger. In your average WordPress hack story, the usual suspects are typically an old or otherwise unsafe plugin or a very old version of the core. In this latest "IT horror" story instead the core update and a delay in the updates are to blame. Unfortunately even the staples of security plugins such as Sucuri, iThemes and many others were basically forced to sit in the passenger seat and simply passively observing (and documenting) what was going on because the breach was in the core itself. Any WordPress site that wasn't patched on time was at risk: if you have a WordPress site, make sure it's up to date.

How can you prevent these issues?

Every member of the WordPress administrators community eventually becomes, in one way or another, well versed in dealing with nasty hacks or infestations of different kinds. After all, a CMS that runs such a significant portion of the known internet will always have a big target on its back. Luckily in this occasion the fix to this issue was relatively simpler than your average exploit; the more time consuming part in this case is getting Google to re-index the defaced content (after fixing it or restoring a previous version). This can all be avoided if your site is properly updated and by ensuring that your site, plugins and DRP are always up to date. If you are eager to find out more details on the incidents, you can check out some interesting statistics on this event in this technical article from Sucuri, where the names of the major hacker groups have been disclosed together with the initial numbers of their campaigns. If your WordPress site has been hacked and you'd like help or advice on how to fix it, feel free to get in touch here.