A Feeding Frenzy to Deface WordPress Sites
In this report we share data on the ongoing flood of WordPress REST-API exploits we are seeing in the wild. We include data on 20 different site defacement campaigns we are currently tracking.
We show how attackers have switched to the REST-API exploit and how it has increased their success rates. We have also seen an evolution in the attack method targeting the REST-API exploit and have evolved our rule-set accordingly. We also demonstrate how hackers are competing to deface sites using the REST-API exploit.
This report highlights the immediate need to protect your site against this attack. Both our attack data and our site cleaning team’s observations are indicating that this attack is having a wide impact.
Background on the REST-API Vulnerability
On January 26th, WordPress released version 4.7.2 which contained a security fix for a vulnerability that allows attackers to modify content on a WordPress site. They did not announce the fix at the time so that attackers would not be aware of the vulnerability while the WordPress auto-update mechanism updated vulnerable sites.
The hidden security fix was announced on February 1st, six days later, at which time attackers became aware of the exploit. By that time a substantial number of WordPress websites had updated to version 4.7.2.
We immediately deployed a firewall rule to our Premium customers on February 1st and started logging attacks targeting the REST API vulnerability. We didn’t see many attacks until February 3 when volume started picking up.
Attacks continued and February 6th we saw attackers had discovered a new variant on the attack which bypassed our rule and the rules that other firewall vendors had put into place. We immediately deployed a second rule to our Premium Wordfence customers which was pushed out in real-time early on February 6th.
The new rule is in red on the chart above and shows how attackers massively ramped up the volume of attacks they were launching using this new, more successful variant of the attack. The chart above is up to midnight last night, Pacific time. We have confirmed that the second newer variant of the attack still bypasses at least one major cloud firewall vendor as of 10am PST this morning.
This vulnerability has resulted in a kind of feeding frenzy where attackers are competing with each other to deface vulnerable WordPress websites. During the past 48 hours we have seen over 800,000 attacks exploiting this specific vulnerability across the WordPress sites we monitor.
If you are using Wordfence Premium, you are fully protected against this vulnerability, even if you are running an older vulnerable version of WordPress. There are multiple variants of the REST-API exploit and the Wordfence firewall Premium rule-set protects against all of them.
Tracking REST-API Defacement Campaigns
The attackers using the REST-API exploit are defacing websites by leaving their own signature on a defaced WordPress page. We are currently tracking 20 different defacement campaigns.
The table below shows the total attacks for each campaign, the number of unique WordPress websites attacked and the number of IP addresses that each attacker is using. On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.
Success Rates for REST-API Attack Campaigns
To determine which campaigns have the highest success rate, we did a Google search for each campaign name in quotes. This gives us an indication of the approximate number of defaced pages per campaign. The actual numbers are in the table above in the far right column.
In some cases the attacker may have used a different exploit to deface a page. However, as you’ll see below, the number of defaced pages for each of these campaigns has increased dramatically since the emergence of the REST-API exploit.
How the REST-API vulnerability has increased total compromised sites over time
By using Google Trends, we can get a good indication of the success rate of our attackers over time. Using Trends, we found that since mid 2014, these campaigns have had little success compromising websites.
Then starting in early February when the REST API vulnerability was disclosed, the success rate for these campaigns massively increased. Google started indexing compromised pages and it shows up in Google trends:
If we change the scale of the chart to just show 2017, you can see the huge spike in success these attack campaigns have had infecting WordPress websites using the REST-API vulnerability. This spike coincides exactly with the date the REST-API vulnerability was disclosed.
Well Known Attackers Switching to the REST-API Exploit
Lets take a look at our top defacer. If we look at the list of MuhmadEmad’s compromised sites on Zone-H.org, he usually drops a file called krd.html or defaces the home page. The content usually looks like this.
On zone-h, which is an archive of hacked sites, it is clear that he took a break for a couple of days after the REST-API attack emerged on February 1st, perhaps to develop a new exploit.
Then he started attacking starting February 4th, and you can see the compromised URLs change to individual defaced WordPress pages:
Hackers Competing to Compromise Sites
In some cases we are seeing hackers competing to deface sites. On the defaced page below you can see HolaKo has defaced the current page, and the link to the next page shows that the following page is defaced by ‘Imam’.
In some cases we can see defaced pages being defaced again by another attacker. The hackers are getting hacked. This page was defaced by ‘Imam’:
But when you visit the page, the title has now been changed to show another defacer has taken over.
Sites that suffer from this vulnerability will continue to be defaced and re-defaced until they either install a firewall like Wordfence or upgrade to WordPress 4.7.2.
Top 25 Attacking IPs Exploiting the REST-API Vulnerability
The following is a list of the top 25 IP addresses by number of attacks, that are exploiting the WordPress REST-API vulnerability. If you are a security researcher you’re welcome to download this table and incorporate it into your own research.
Conclusion
This is one of the worst WordPress related vulnerabilities to emerge in some time. Our site cleaners have been working with site owners all week to help them clean defaced sites. In every case the customer was not running our Premium firewall and had not updated to WordPress 4.7.2.
If you have not been able to update to WordPress 4.7.2 but are using Wordfence Premium, you have been protected against this since exploitation started.
As always, I will be around to reply to your comments.
Mark Maunder – Wordfence Founder/CEO.
Comments
11:08 am
Does this mean that if your site is 4.7.2, then your site isn't subject to this specific exploit?
11:17 am
Correct.
11:53 am
Thank you.
11:12 am
Which versions of Wordpress are vulnerable?
Everything before 4.7.2? or earlier 4.7 versions only?
11:17 am
Version 4.7 and 4.7.1 are vulnerable to the REST-API exploit.
11:14 am
"In every case the customer was not running our Premium firewall and had not updated to WordPress 4.7.2."
Mark, since WP pushes out minor updates, anyone running 4.7 or 4.7.1 should have received the 4.7.2 update automatically. Can you elaborate on the reasons why a site would not have automatically received the 4.7.2 and what those site owners could do to insure they receive future minor updates automatically?
Thanks for another very informative blog post!
- Scott
11:16 am
You should be updated to WP 4.7.2 and any other 'minor' updates automatically if you have a default WP config and your filesystem is writable. Some people have disabled automatic updates. Others don't have a writable filesystem.
This link should give you the info you need to configure auto updates if they're disabled: https://codex.wordpress.org/Configuring_Automatic_Background_Updates#Constant_to_Configure_Core_Updates
If you can install plugins from the web interface, then your filesystem is probably writable and will be able to auto update if you haven't disabled it.
Mark.
11:15 am
I work at a webhost. We've seen 2-3 of these, mostly the RxR ones, but other than that surprisingly quiet, considering the number of likely outdated WordPress versions clients are likely to be running without updates.
5:01 am
This particular Vulnerability will affect the site which are on 4.7.0 or 4.7.1 only.
If older version than that, they'll be good!
5:02 am
That is according to the WordPress.org blog. We have not, however, verified this.
11:19 am
Thanks for the info, but how boring are these people that they want to deface wordpress sites anyway? Each to their own I suppose but I'd say to them get a life and do something original.
11:26 am
Mark,
It's almost impossible to keep up with all the Cyber security issues...Don't know what we would do without Wordfence....Keep up the good work!
Thanks
11:29 am
Wow,
Is it Time to pull the plug on WordPress?
11:34 am
No, absolutely not. You're likely to jump to a less popular CMS which has many more exploitable vulnerabilities without security vendors that support you, like us. WordPress has a mature security community and established ways of finding vulnerabilities and deploying fixes. All you need is a good firewall like Wordfence and to keep abreast of security news. If all you do is install Wordfence Premium, you're extremely unlikely to ever experience a security issue.
Mark.
11:45 am
Totally agree with Mark! Joomla and Drupal were absolute security nightmares for many years. I didn't want to change some of my customer sites from Joomla, but we were getting hacked once a week, despite all that we did (and tools like Wordfence were rare). Ultimately, we had to switch because of the problems. To be fair, it's much better in Drupal and Joomla lands, but it's not nearly as mature and safe as WordPress is. Just make sure you keep up to date, use awesome tools like Wordfence, and you shouldn't have a single problem.
11:39 am
My site was also hacked by this method. Wordfence was not installed before, I put it up since then. What steps should I take?
11:44 am
Upgrade to Wordfence Premium if you can afford $8.25 per month. If not, you will receive the firewall rules that protect you against this vulnerability 30 days after they were released, which is early March. If you are running free Wordfence, make sure you have also updated to WordPress 4.7.2.
Mark.
11:52 am
Mark, you mentioned in a prior comment / response to Bill Davis that if you have upgraded to version 4.7.2 that you were protected, but this comment / response to Mr. Varga that even if 4.7.2, you will not be protected without Premium until early March. Can you please clarify?
If your response to Mr. Varga is correct, what is the level of risk until early March of not upgrading to Premium (with 4.7.2 installed)?
12:08 pm
If you are running WordPress 4.7.2 you are not vulnerable to this attack.
If you are using 4.7 or 4.7.1 you are vulnerable.
If you choose to not upgrade to 4.7.2 for some reason, you will still be protected by Wordfence provided you have a Premium license and your firewall is fully enabled.
However, to be clear, we recommend that everyone upgrade to WordPress 4.7.2 as soon as possible, rather than just relying on the Wordfence firewall. The firewall is there to catch attacks that occur before you upgrade to a security update.
Mark.
11:46 am
Other than defacing sites, have you seen anything more malicious in the payloads? Any injection of malware onto sites?
BTW, you're posts are always really informative and useful. Thank you!
12:10 pm
Not that I'm aware. We have only seen defacements in REST-API exploitation. However I will consult with the senior site cleaning folks and update here if I receive reports of anything additional.
Mark.
11:47 am
Did the attackers live some malware in the site code after site been compromised? Or you just update your wordpress core to 4.7.2, restore content on the compromised page and everything became normal?
12:09 pm
I'd have to consult our site cleaning team, but as far as I'm aware, your comment is accurate. If you are compromised, the fix is to repair modified posts and update to 4.7.2.
Mark.
11:55 am
We had 4.7.1 and not 4.7.2. but we have WordFence premium and our site was still compromised by this hack. Is there anything that has to be turned on in the firewall for Wordfence to have protected us?
12:06 pm
You would not have been protected if you weren't running Wordfence Premium. The rules are pushed out in real-time to Premium. They are 30 days delayed to the free version.
5:41 pm
Jared, we had 16 sites running Wordfence Premium and either WordPress 4.7 or 4.7.1. Around 8 sites were attacked using this exploit, but only 1 site was actually defaced.
Through our investigation (and support ticket with Wordfence), we discovered that the Firewall had reverted into Learning Mode due to the wp-content/wflogs/ directory being removed during a deployment. This caused it to stop preventing attacks.
I'd be checking that first, if you don't have a *.rules file in the wp-content/wflogs/ directory (or it hasn't been modified/updated in a long time), then your firewall isn't protecting you.
We've also made the suggestion to the Wordfence team that they add an automated alert email if this situation occurs. If someone manually deactivates the firewall it already notifies you, but if it switches off for some other reason then you have no way of knowing.
They said it's a good idea, so we'll see if that gets implemented. In the meantime we're checking the Firewalls on our other sites.
Finally, if you still don't have an explanation for why your firewall failed, definitely log a Wordfence support ticket! You need to be confident in the security of your site, and if something else has gone wrong they might be able to implement a solution (or update their troubleshooting documentation).
Hope this helps!
(Disclaimer: I do *not* work for Wordfence)
4:53 am
No you do not, but it sounds like you could. And we're super happy to have you as a customer. :-) I saw discussion about this on our internal Slack. Thanks for posting.
Mark.
4:18 pm
thanks for the advise!
4:58 am
Sorry Jared, I just re-read your post and realized I hadn't noticed you were running Wordfence Premium. In my defense I had just gotten off a 30 hour flight, so I blame severe jet lag.
Please reach out to our support team immediately if you haven't already. As another commenter already pointed out, your firewall was probably in learning mode. In their case, a deployment had removed a few Wordfence directories which caused that. It's an extremely unusual situation they encountered and not something we've seen before.
The team will help you determine what happened and if you need help cleaning things up, reach out to me at mark at wordfence.com and I'll see what we can do.
Regards,
Mark.
4:17 pm
Hi,
Thanks for all the replies here. I didn't get a chance to check back until now. Yes we were running Premium, no problem about the misunderstood response:). I'll open a ticket with you guys and we can check to make sure everything is set up properly on our end.
Thank you!
12:05 pm
Yep, this got me, I didnt update fast enough. I haven't got auto updates on still because I haven't got round to configuring selinux to allow it to.
Wordfence free is a great plugin, and the wordfence blog is extremely helpful. However, I wish wordfence premium were cheaper. For a tiny non profit site like mine $99 is a lot. My hosting cost is only $15 a month. Its all very well stating its only $8.25 a month, the problem is i see no option to pay monthly?
12:13 pm
That's correct. Unfortunately our pricing is currently $99 per year and that's the only pricing option.
I wish we could drop the price, but we are a team of almost 30 people now and many of us work extremely hard to do the research that generates the rule-sets and malware signatures. I should point out my colleagues tend to work harder than me. :)
All those rules and malware sigs do become free after 30 days, so the community edition of Wordfence is a pretty good deal. It's just not feasible for us to provide the rules and malware sigs to free users in real-time. I wish it was.
Mark.
5:38 am
I second the notion of less expensive premium and believe you'd make more money if you lowered the price but you might need to do it through a partner program to avoid support costs consuming the extra income and then some. I build and operate websites for nonprofits. At current pricing, less than 2 in 20 of my customers is using Wordfence Premium but they all use Wordfence. If the price was more like I pay for backup ($2/mo.), they'd all be on Premium and you'd have nearly 2.5 times the revenue. If this was done through a partner program where I was first line of support for my customers, your incremental support cost would be marginal. If you sold directly at that price the support cost increase of 10X customers at 1/4 the price may not work so I see why you don't lower the end user price. I wish you'd consider a partner program.
9:52 am
Pricing theory is voodoo magic. :) There are two sides to the argument here. The other side is that current commercial vulnerability scanning tools are thousands of $$ per year. Most of Gravityscan is free and the paid version is quite reasonable if you do some market research.
But arguing with my customers over pricing is always going to be a losing battle IMHO.
Thanks for the feedback Scott!!
Mark.
12:25 pm
Once the site is defaced in this way, do the hackers put a backdoor in place and are passwords compromised? With sites that are defaced in this way, once WordPress is updated and/or the firewall in place, are there other steps needed to prevent further defacement?
12:40 pm
Hi David,
The sites we've seen defaced only have modified content. So yes, the steps are, update to 4.7.2, install firewall, fix content. And then you should be OK. However....
If you have enabled PHP execution in your site content, or if an attacker manages to inject a shortcode which gives them code execution via a plugin, then all bets are off. Your site may be fully compromised.
In addition, if an attacker is able to inject an XSS payload which compromises an admin account, then again, your site will be fully compromised.
Sorry the answer isn't black or white. In reality if you have been compromised, it's best to have a professional look at the site and do a full security assessment. The alternative is that you may have a site you think you cleaned, but it stays compromised without you realizing.
So if you have been hacked, contact our site cleaning team and they will help out. We provide excellent service and (most people don't realize this) great volume discounts.
Mark.
12:48 pm
Thanks for that clarification, Mark!
1:40 pm
I use wordfence on all my sites now, I also had 2 clients on premium 3 years ago. I must say that Wordfence is indespensable. The free version is powerful also! Before putting wordfence on all client sites, they were all hacked, even the ines that were updated a day before beung defaced.
The page read Hacked by Skorpiol, seems to be out of Turkey. Because I didnt have wordfence at that time, the mass defacement was possible and happened rapidly; over 15 of the sites were hacked. I had to start reinstalling and activating wordfence and the WAF, in some cases just using Wordfence to scan and it restored original core and plugin files, amazing feature!
Keep up the good work with Wordfence. Soon we'll be able to afford premium in my country, for now we are facing a recession and the 99 usd is tough for almost all my clients
4:16 pm
Another instance is "hacked by NG689Skw". Happened to my website.
Then i used wordfence scanner. Looks like they left a backdoor in GZIP format in one of my plugin folder i deleted that plugin. And update WP.
Fyi..
4:41 pm
I'm hardly surprised. When I heard that 4.7 would have a new REST API, I saw "security hole" written all over that. I've been holding several of my WP sites back at 4.6 until something like this surfaced and got patched. For the few that I updated to 4.7, I installed the "Disable REST API" plugin to make sure that the REST API was not going to be available as a potential attack vector.
Thanks for the post, and for staying on top of these kinds of things for us all.
1:51 am
Here's a classic example of where automatic updates of WordPress are a bad idea. I'm glad we waited before manually updating to version 7!
3:50 am
I would like to hear from you guys if an SSL encrypted web page is better protected against these kinds of attacks or if it is the same as normal non SSL protected web page. I am also a user of the Worfence free plugin and its an awesome tool even though I am on the free version the alerts are really helpful.
Kaj
5:02 am
Hi Kaj,
SSL only protects the confidentiality of data in transit. It does not prevent malicious requests from reaching your site. So no, it does not help protect against this.
Regards,
Mark.
6:45 am
I understand disabling REST API through code options with plugins or filters, and appreciate the need to keep WordPress updated and benefits of WordFence Premium. That said, does denying all requests to paths at /wp-json in the web server configuration disable all of the default WordPress core REST API access? are there are URL paths by default?
7:29 am
This is why I think it's irresponsible for the wordpress managers and devs to put all these new automation features into the platform, apparently without extensive security screening, and defaulted to ON. It puts us all at risk and keeps us up at night worrying about new potential breaches to our websites. I don't need a rocket ship platform to run my blog. I just need a pickup truck that gets the job done reliably, securely, and effectively. I recommend the following plugins for those who want to run a minimalist site. To each his own of course and everybody's needs are different.
Plugins: Disable Comments, Disable REST API, Disable XML-RPC, WP Force SSL (if your site is capable, won't affect this hack). By the way, when my ISP updates my wordpress lately, it adds extra deactivated plugins in my list, which I have to go delete. Just something to be aware of for some users with managed accounts. May have to raise an ISP trouble ticket on that.
I also have the following, among hundreds of others, in my URL block list based on attack patterns I've seen in the logs.: /admin-ajax.php, /ADMIN-AJAX.PHP, /admin-ajax.php*, /ADMIN-AJAX.PHP*, /admin-ajax.*, /ADMIN-AJAX.*, /admin-ajax*, /ADMIN-AJAX*, /ajax.php, /AJAX.PHP, /ajax.php*, /AJAX.PHP*, /ajax*, /AJAX*, /ajax.*, /AJAX.*, /wp-json, /WP-JSON, /wp-json*, /WP-JSON*, /wp-json.*, /WP-JSON.*, /xmlrpc.php, /XMLRPC.PHP, /xmlrpc.php*, /XMLRPC.PHP*, /xmlrpc.*, /XMLRPC.*, /xmlrpc*, /XMLRPC*
The block list is case sensitive, hence variations for case and with and without wild cards.
This WILL break sites that use advanced automation features, so use at your own risk. Works for me though.
Ron
3:08 pm
Who is your host that is adding things? I now Godaddy adds a bunch of junk.
10:08 pm
I'm currently with 1and1, though that's subject to change. These may just be standard plugins that come with 4.7.2 that I wasn't using before. They pop in deactivated when the ISP updates WP. Still, I didn't ask for them and I'd rather they weren't there.
Ron
9:25 am
I completely agree with you.
The Rest API functionality is not necessary in almost all sites, maybe the Wordpress developers needed new eye-catcher and so hasty to include it as rival CMSes such like Drupal 8 bruiting its restful service.
But again, it was overhasty to enable it on ALL Wordpress sites by default without any option to disable it.
I think they should add an option to toggle the Rest API, or put it into JetPack or something like that in 4.7.3.
2:51 pm
I have a f ew hundred posts over 30 websites, all have been updated to version 4.7.2. but I cannot manually check all the post so is there an easy way to find out if any post have been hacked before I was able to update them all?
Lee