Revslider, MailPoet, GravityForms Exploits Bypass Cloudflare WAF
Update: We have received reports from a plugin vendor that there may be some confusion about whether or not the plugins referred to in this post are still vulnerable. The vulnerabilities we refer to in Revolution Slider, MailPoet, Gravity Forms and Timthumb have been fixed since they were first discovered. There are new, updated versions of all of these plugins available and these updates have been available for some time. If you use any of these products, we encourage you to update to their newest versions.
/End Update.
Last week we blogged about the advantages of endpoint security over a cloud firewall solution. We wrote about how cloud WAFs can be bypassed. We also blogged about how it is more challenging for a cloud WAF provider to write complex firewall rules because cloud WAFs don’t know if a user is signed in or what their access level is.
Part of the forensic research we do at Wordfence involves analyzing attack data we receive from sites that use Wordfence. We use a scaleable database cluster to perform big data analysis on WordPress attack data. We identified many attacks that were bypassing Cloudflare and being blocked by Wordfence. So we dug a little deeper.
Cloudflare Pro provides a web application firewall that is designed to perform a similar function to the Wordfence WAF. We are in that sense, direct competitors. We wanted to evaluate the Cloudflare WAF and to get access to it you have to get a paid ‘Pro’ account for $240 per year or $20/month. So we bought and paid for the Cloudflare WAF.
The default Cloudflare WAF sensitivity setting is ‘Medium’. We increased the sensitivity setting to ‘High’. That is the highest sensitivity setting before your users have to get through a captcha to access your site.
We also enabled every rule we could find in the Cloudflare WAF. That includes 11 rules in the “Cloudflare ruleset” and 20 rules in the “OWASP ModSecurity Core Rule Set”. We also put that ruleset on “High” sensitivity. We also enabled the “browser integrity check”.
We enabled absolutely everything we could find and put everything on “High” sensitivity.
We then confirmed that we could bypass the Cloudflare Pro WAF with the following attacks using no special techniques:
- Revolution Slider – We gained a remote shell. This went through completely undetected.
- MailPoet – We gained a remote shell. Also completely undetected.
- Gravity Forms – We gained a remote shell. Also completely undetected.
- Timthumb – Gained a remote shell using the .phtml form of the attack. Detected but not blocked.
These results were surprising. We used off-the-shelf hacker scripts without any special modifications. It’s well known that RevSlider, Gravity Forms and Timthumb are three of the leading causes of hacked websites. According to one report, 25% of hacked sites are hacked through one of these three WordPress exploits. Cloudflare Pro at $240/year with a ‘High’ sensitivity setting and all rules enabled allows these attacks through.
The free version of Wordfence blocks all of these attacks.
Why do these well known attacks bypass Cloudflare?
We don’t know why Cloudflare allows these attacks through, as surprising as it is, but I’d like to share a few observations. Firstly, Cloudflare is not WordPress specific. They are trying to be a firewall for all web platforms which is a difficult, perhaps impossible, challenge. Wordfence is WordPress specific, so we are able to tailor our rules for attacks that we know target that platform specifically.
Cloudflare is a ‘cloud WAF’ and, as we have pointed out previously, because their servers and rules run out on the Internet, they don’t have access to authentication and authorization data to make their rule decisions. Wordfence on the other hand knows if a user is signed in, what their identity is and what their access level is, so we are able to write more complex and stricter rules.
Demonstration
We have created a video demonstrating Cloudflare being bypassed by these exploits. In the first test we have a site that is filtering traffic through Cloudflare Pro with all rules enabled and on a ‘High’ sensitivity setting. In this test we also enable the free version of Wordfence on our target site. This allows us to see the attacks bypassing Cloudflare and being blocked by Wordfence.
In the next test, we remove Wordfence completely from the target site and demonstrate how, without it, the site is exploited by an attacker, completely bypassing the Cloudflare Pro WAF on ‘High’ sensitivity.
The following is a video demonstration of this attack. In it we use two Linode servers, one as our attacker and another as our ‘Victim’. We use a Cloudflare Pro account on ‘High’ sensitivity with all rules enabled. We also download and configure the free version of Wordfence for the first part of the demo, and then remove it.
Why does this matter?
The free version of Wordfence blocks all of these attacks. They are what we consider “the basics” when it comes to WordPress security. If you pay us $99 a year you also get a real-time feed of emerging threats. Cloudflare are selling a web application firewall for $240 per year that allows through the best known and most dangerous WordPress attacks.
That means you can get better protection by using our free product than by using the $240/year Pro Cloudflare WAF. Then, if you choose to upgrade to our paid option, you know you’re protected against the newest emerging threats against WordPress.
It’s important to us that our customers know this. We feel we would be doing you a disservice if we didn’t share this comparative data. If you want to protect your WordPress site from a hack, you need a WordPress specific firewall that runs on the endpoint and protects you against “the basics” and also against emerging threats.
Conclusion and Technical Notes
We have provided a public Github repository that include tcpflow packet captures from the perspective of the attacker and from the perspective of the victim. The repository also includes the four exploits we used. Note that you will need to edit the exploit files to add in your own target hostnames. In the case of Timthumb you will also need to add a server from which timthumb can download an attack shell.
We have not included the vulnerable plugins or theme. However, we are supplying their versions. They are: Gravity Forms 1.8.1, MailPoet 2.6.4, Revslider 2.3.91 and Timthumb version 1.12. You can find these in the WordPress.org repository, in other repositories on github and elsewhere.
If you do download and test one of these vulnerable products and find you’re not able to exploit them, you may be using an old version that has a back-ported security fix. So please note that you need to find both a vulnerable ‘version’ of the product and one that has not had a back-ported security fix applied.
As always I welcome your comments and questions.
Trademark notice: All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.
Comments
10:44 am
Impressive work, Mark!
So when is your CloudFlare / Sucuri alternative SaaS launching? :)
5:32 am
Is it sarcasm or does WordFence plan to have a cloud based firewall or CDN?
9:42 am
We have no plans to implement that. I don't think 'cloud' and 'firewall' are two words that should be combined. We focus on providing endpoint security.
10:47 am
What about other WAF solutions? Do you have any data on how those behave with Wordpress vulnerabilities? I'm specifically thinking of what I'll call the hardcore WAF solutions, that "learn" about a web application over time and know what type of traffic/data is valid for a given application.
10:48 am
Interesting, thanks
I don't suppose you've tried the same tests on sucuri's cloudproxy thing by any chance? I might give a go myself
Also, how come you don't post all these blogs on your facebook page?
Thanks,
Jason
10:49 am
Thank for doing this great work
10:50 am
Wondering if you contacted Cloudflare for comment before publishing this article? If not then that'd seem pretty bad form...
10:56 am
I can't comment on whether we chatted to Cloudflare. You should note that this is not a vulnerability that lets you gain access to a product/service. It's a product comparison.
11:11 am
Why can't you comment on whether or not you contacted Cloudflare if all this is is a product comparison. Or even just appearing to be fair and unbiased. :) (On the other hand, if I'd spent $240 on Cloudflare and read this, I'd be jumping up and down like Yosemite Sam. Do you know how many pairs of shoes $240 can buy?!)
11:12 am
Those exploits are 2 years old? How is this relevant?
11:40 am
A large portion of hacked sites we see (and that others see - check the link in the post) are compromised through one of these vulnerabilities. Even today. Furthermore, protection against these vulnerabilities is what I'd consider an excellent benchmark for a WordPress firewall.
11:57 am
I think that this test is right with these vulnerabilities because they are well known and is a right test for future vulnerabilities.
12:40 pm
Hi,
So I have wordfence free version on several sites, and have pro on others. I also use Revslider on most of them. Am I to understand that RevSlider current versions are a threat? And if so, is Wordfence protecting the site from such attacks, or have I wasted hundreds on Revslider licenses and a ton of design time but now need to opt for an alternate that may or may not have the same or other vulnerabilities?
My stomach is bleeding here...
1:12 pm
Hi Robyn,
As far as we're aware there is no current revslider vulnerability, although I haven't checked in with our security team and we haven't audited their code. In the blog post we're referring to an older very well known and widely exploited revslider vulnerability. It caused, and continues to cause, widespread damage to WordPress sites.
Mark.
12:52 pm
Awesome post as always! Would, as someone else also mentioned, be very interested in Sucuris result in a similar test too.
12:55 pm
THANKS MARK!
1:14 pm
Completely agree with your comment (although not an excuse) that CF is agnostic to the website technology that sits behind it so may not have tailored rulesets available to target WP exploits. You could probably say the same for Akamai (which costs a great deal more than $240/year) or other commercial grade WAF services. There are many types of attacks that those SaaS services do prevent (such as many types of denial of service) where blocking the attack before it reaches the site it critically important. My point is that comparing CF and WordFence is not a direct functional match; there is a lot of overlap but WordFence provides things CloudFlare does not while cloud-based WAFs provide some features that WordFence does not.
1:49 pm
Agreed. Our main concern is that WP customers don't get into a frame of mind where they think the CF WAF will protect against WordPress attacks. It's clearly not doing a great job, even though it includes WordPress specific rules in it's rulesets.
Thanks for the feedback Steve.
2:06 pm
Thanks Mark. This is so interesting and it is so good to know that our Wordfence security is working so well for us.
4:36 pm
Yes you're right, I'm the victim a couple times. The rev slider vulnerability is painful, all of my theme and plugin always up to date, but still got hacked because that rev slider. CloudFlare firewall can't protect me.
Now I uninstall the revslider and using more security plugin and another web firewall, now I live in peace :)
5:49 pm
Buys $250/year firewall
Now what to do ?
How about update 1 year old plugins .
Nah, they works fine . And what can go wrong ?
Also , since this is cloudflare firewall exploit. Did you report this to cloudflare before writing ?
7:57 pm
It's not an exploit that lets you gain access to Cloudflare or anything specific if you're using Cloudflare. It's a bypass using a well known publicly disclosed exploit in the CF firewall rules.
6:27 pm
tank of thanks wordfence. Keep it UP!
12:20 am
Verry glad to have WF on all my blogs.
Thanks to all of the Team!
Perfect work.
I wait for the answer from WAF
6:02 am
Cloudflare firewall will always remain a joke until you are able to completely hide your IP. Hiding IP is not that easy specially on shared host or for non-tech users. There are many ways to find real IP and yes there is always more than 50% chance to get real IP. Once you found real IP, put it in your host file and here goes $250/year firewall in drain.
5:41 pm
Hi Noman Riffat - you can block all access to your web server other than via the cloudflare ip ranges if you like
9:53 am
Did your tests assume that the only traffic allowed to the target website was from IP addresses originating from Cloudflare?
10:36 am
We confirmed the attacks in the test, and we performed multiple tests, came via the Cloudflare WAF. So to answer your question, setting up a rule where the only traffic that is allowed is traffic that arrives via Cloudflare would not have protected you against this attack. The point is that these exploits sail right through the Cloudflare WAF on 'High' sensitivity with all rules enabled.
10:14 am
And how does incapsula perform on this test?
11:42 am
Mark,
Is there any information available regarding if these attacks are getting through for those users who are using CloudFlare AND have WordFence installed? Assuming CloudFlare lets it through the WordFence plugin should still grab these issues correctly? Just want to make sure that there shouldn't be any specific conflicts that anyone is aware of?
2:54 pm
Hi Derek,
I wanted to include metrics on actual numbers but didn't have time. What we get reported to us is attacks that Wordfence blocks because it recognizes them as malicious. We can tell that it came via Cloudflare because of the HTTP headers e.g. the CF-RayID header and about 2 or three others. We're able to then verify that it is a cloudflare customer by doing a whois or reverse lookup on the connecting IP address or we can simply confirm the target website is a cloudflare customer by doing a forward lookup on the website hostname.
So we started noticing these bypasses and then took a look at a few specific attacks. We started with the worst and most well known first and it turns out that all four of them get through - and all are completely unmodified except for timthumb which is a variant on the standard timthumb attack.
Mark.
6:39 pm
Mark,
Not entirely sure if my question was answered? It could be my late hour? So forgive me if you covered this,
In plain English - Did using CloudFlare cause a WordFence Protected site to allow access?
OR
Did the attack type "Pass-through" to the website, where by WordFence Stopped it?
To me this is pivotal question. I have sites using CloudFlare but I also install WordFence on all my sites. If Cloudflare missed an issue that WordFence then caught, I can keep using CloudFlare. If however CloudFlare somehow caused it to Bypass WordFence completely, then by all means I need to change those sites.
8:42 am
I thought we were quite clear on this. So your question leaves me concerned that the post wasn't clear enough.
The attack passed through Cloudflare and was stopped by Wordfence. The introduction of Cloudflare did not introduce a vulnerability. It simply did not do the job it's supposed to do.
Mark.
3:00 pm
By 'it' I meant Wordfence, of course, not CloudFlare.
7:53 am
Hi; I work for Cloudflare. Just wanted to confirm that in the hours following this disclosure, we did indeed add additional WAF rules to prevent the attacks outlined here, we added these a matter of hours after this blog post went up.
The WordPress WAF rules can be further customised by clicking the rule group after toggling the "Rule details" section. This allows you to enable and control the behaviour of each individual WAF rule.
8:01 am
Thanks for the update Junade! Very much appreciated.
Regards,
Mark.