Episode 68: More Plugin Vulnerabilities and Active Attack Campaigns
This week, we review numerous plugin vulnerabilities in popular WordPress plugins and the attacks that are targeting them. We also review the Duplicator vulnerability affecting over 1 million sites, and Chloe Chamberland’s discovery of multiple vulnerabilities in the Pricing Table by Supsystic plugin. Some WordPress-focused companies, Elementor and Strattic, receive venture funding.
We also ask lead customer support engineer Tim Cantrell about the different ways to use Wordfence settings for brute force protection, blocking IP addresses, and how to prevent alert fatigue.
Here are timestamps and links in case you’d like to jump around, and a transcript is below.
1:10 Site Takeover Campaign Exploits Multiple Zero-Day Vulnerabilities
4:45 Active Attack on Recently Patched Duplicator Plugin Vulnerability Affects Over 1 Million Sites
8:12 Multiple Vulnerabilities Patched in Pricing Table by Supsystic Plugin
10:00 Multiple Attack Campaigns Targeting Recent Plugin Vulnerabilities
11:19 Venture funding to Elementor and Strattic
15:44 Ask Wordfence with Tim Cantrell: Brute force protection, blocking IP addresses, and preventing alert fatigue
Have a story you’d like us to cover? Contact us at press AT wordfence [dot] com.
Episode 68 Transcript
Hello my WordPress friends. And welcome to episode 68 of Think Like a Hacker. This is the podcast about WordPress, security, and innovation brought to you by the fine folks at Wordfence. Wordfence, obviously a security plugin, securing over three million WordPress sites. We have a firewall that protects your site from malicious attack and a malware scanner that alerts you if you have been compromised. And that’s my pitch for today.
Did you catch episode 67 previous to this? That was Ram Gall’s talk at WordCamp Phoenix about the most common mistakes found in plugin vulnerabilities. So if you’re writing plugin code for WordPress sites, Ram’s talk helps you identify some of the most common problems, well, the common problems we’ve seen, when plugins have significant vulnerabilities. Definitely check that out. You can see all of the slides on the YouTube video of his talk at WordCamp Phoenix. And with that mention, we do have a few plugin vulnerabilities to go over this week. So let’s dive into the news.
First up, let’s talk about an active campaign that the Wordfence threat intelligence team has identified. On February 26th, our friends over at the Ninja Technologies Network posted that a zero-day vulnerability had been fixed in WordPress Flexible Checkout Fields for WooCommerce. This was a plugin with about 20,000 active installations and this vulnerability was zero day. It was being actively exploited. It affected versions 2.3.1 and below. And that active exploitation had been happening for a few hours and there were some notes on wordpress.org in the support forums for that plugin.
Our team reached out to the plugin’s development teams to help them resolve these issues as quickly as possible. As always, our Threat Intelligence team developed and released firewall rules to protect against active exploitation that was happening. So Wordfence Premium users have already received these protections and Wordfence free users will receive them in 30 days.
Fortunately, because these vulnerabilities were being exploited to inject cross site scripting payloads, these attacks were for the most part being blacked by the built in cross-site scripting protection available to all Wordfence users, whether you’re using the free plugin or premium. However, because of the nature of these vulnerabilities in each of these plugins, there were some other disruptive activity that we can’t really get into because of security reasons that could not be blocked by that built-in cross site scripting rule. So it’s really important that you take a look and if you have any of these plugins on your site and at the time of your listening they have not been patched, you either need to put additional protections in place like Wordfence Premium or we recommend that you remove those plugins. Don’t just deactivate them, but actually remove them, delete them from your site in order to keep your site safe.
So we’ll have a link to the blog post in our show notes that will go over the different vulnerabilities that were discovered in these plugins and we will have a follow up post in the next week that gives you some idea of what this active campaign is doing. Right now, we just wanted to let you know as soon as possible that we saw an active attack happening. We’re working with the developers to get these patched. We’ve released firewall rules. We’re doing what we can… And informing you is part of what we can do.
And what you do with your site is obviously up to you. If you keep these vulnerable plugins on your site, just make sure you have adequate protection or make sure you have backups, because this active campaign could be something that targets your site as well.
Next up was a blog post that we posted last week. This was covering the Duplicator plugin vulnerability that affected over a million sites. Duplicator is a plugin that basically allows you to take a copy of your site and move it elsewhere. This is installed oon over a million sites. There’s also a pro version and we have an estimate that that pro version is about 170,000 WordPress sites using that.
Both the pro and the free version of Duplicator are affected by this vulnerability, so it’s very important that you have the latest version of Duplicator on your site, if you need on your site. This is one of those plugins that I consider removing if I’m not actively using it because it doesn’t have anything that is required for the front end functionality of a site. It’s questionable whether or not you need to leave it on your site at all. Sometimes people use it for backups. So there could be reasons that you may want it on your site.
Now we found this, Ram Gall, who’s a talk you might have seen in episode 67 or on our YouTube channel, Ram actually found this vulnerability actively being exploited when he was checking some of our threat intelligence. He saw some requests that were getting blocked by the Wordfence firewall. So if you have Wordfence on your site and a vulnerable version of Duplicator, hackers cannot exploit this vulnerable version because Wordfence is blocking access to the files that hackers are after.
So this vulnerability was an unauthenticated, meaning anyone can exploit it, you don’t need to be an authenticated user. Unauthenticated arbitrary, meaning any file whatsoever, arbitrary file download. That means any user anywhere, if they know how to exploit this vulnerability, was able to grab any file.
And now when this happens on a WordPress site, usually the file thereafter is wp-config.php. Wp-config.php is a file that is in the root of every WordPress installation and it contains a number of things. Of greatest consequence are your WordPress, MYSQL or Maria, whatever database you’re using, your database credentials, so the database username and password.
Now if your database that is containing all of your WordPress content does not allow remote access, maybe not a problem, but if it does, a significant problem. So it’s really important to protect that file. Wordfence has built in protections for this and so if you were using Wordfence, whether free or premium, you are protected against this vulnerability being exploited still.
This is one of those plugins that maybe you don’t need on your site all the time. Obviously the front end of your site does not require Duplicator in order to operate. It is something that you maybe use sometimes. And if you’re not using it all the time, it makes sense to remove plugins that are sort of utilities that you use every once in a while. Remove those from your site because when a vulnerability like this comes along, better to not have that vulnerable code on your WordPress site.
On February 25th, Chloe Chamberland posted a blog post about multiple vulnerabilities patched in the Pricing Table by Supsystic plugin. This is a plugin installed on over 40,000 WordPress sites. Chloe discovered cross site scripting and cross site request forgery vulnerabilities in this plugin. She contacted the developers in January, ensured that Wordfence free and premium users would be protected with that firewall rule. At the time of this recording, both free and premium users are protected. Take a look at that blog post.
I really like how Chloe is doing these video walkthroughs of proof of concept. She’s actually showing how a vulnerable plugin can be exploited. I like these because it demystifies security. It shows you exactly how these types of attacks operate. Some hackers might enjoy them because it’s like, oh great, this shows me exactly what to do.
It’s our job as site owners to ensure that our sites are protected and if protection exists, if an update exists to a plugin, it’s important to just make sure that happens. After a patch has been released it’s important for security professionals to share that knowledge with other security professionals and that’s why these proof of concepts are published and why that information is shared, because when that information is shared, kind of like that whole idea of sunlight is the greatest disinfectant, the more people we can show how to keep WordPress and WordPress plugins and themes and basically any web application safe, the safer the web’s going to be.
Another post I wanted to highlight was one by Mikey Veenstra. Multiple attack campaigns are targeting all of these recent plugin vulnerabilities. These types of posts are important because it shows you indicators of compromise and lets you know what threat actors in the WordPress space are doing. So he goes over a couple of different threat actors and the types of vulnerabilities these guys are targeting. Or these girls. Not really sure. TonyRedball, sounds like a guy in a hoodie, right? That’s at least the stereotype that so many people say about hackers. SolarSalvador1234 is the second threat actor that Mikey profiles. These guys are definitely making hay targeting some of these recent vulnerabilities. So it’s our job, again, to keep our sites patched because as soon as a vulnerability is discovered, especially with large install bases, hackers and malicious actors get very busy trying to find ways to exploit vulnerability.
Finally, there are a couple of other stories that I wanted to highlight in the WordPress space. These are not scary stories. These are happy, somewhat interesting stories. We’re done with all the scary plugin vulnerabilities, at least for this week.
First of all, our friends over at Elementor. Elementor is a page building plugin that is currently installed on over four million WordPress sites. I am an Elementor user. I find it extremely easy to teach my non-technical friends how to do some amazing things with Elementor. They received $15 million in funding from Lightspeed Venture Partners.
Our friends over at Post Status broke this story this week and they had an interesting comment about how they are hiring for their cloud team and that cloud team is tasked with building, maintaining and supporting the company’s cloud hosting SaaS solution. Interesting. It will be very interesting to see what Elementor does with this venture funding. It’s an extremely popular page builder, for good reason. It’s very easy to use and very easy to ramp up on. We have some friends at Elementor and definitely wish them all the best in this funding round and can’t wait to see what they do.
In other VC funding, Strattic, a static hosting company based in Israel, as well as Elementor. It seems like all of the venture funding is going to Israel this week. Strattic raised $6.5 million to bring static WordPress to the masses. Now, Strattic has been around for a little while. I’ve met Miriam at WordCamp US I think in 2018 for the first time and have been following along watching Strattic’s journey. There’s a lot of interesting things happening there.
When WordPress came along, I was using a blogging system called movable type and movable type was a Perl-based application that was on your web server and you had an administrative dashboard very similar to how WordPress works and you would type up your blog post and you would hit publish and it would create a static file. It would create a static HTML file, no PHP, and it became incredibly cumbersome at times to work with.
When WordPress came along and it was using the same database class that I was using in my development work, I was like, oh, I can use this for a blog. This is great, and it’s working the exact same way. I work on my 9:00 to 5:00 job, so I jumped onto WordPress and started tearing apart core and putting it back together in ways that better suited me. I don’t do that anymore, obviously, but at the time… It was open source and it was a fairly simple blogging platform and I had developed sort of my own content management system. WordPress was obviously a better solution, jumped into it and never really looked back.
Now that we’re coming sort of full circle back into static sites. I find it very interesting that they are taking all of the benefits of WordPress and the structure and organization of a database and finding ways to make static files occur. Now, it’ll be interesting to see what they do with highly functional WordPress sites, and I’m kind of in wait and see mode. It’s interesting that they’ve gotten some funding here, and I’m interested to see what they do. Miriam and all of our friends at Strattic, I wish you the best of luck with your funding and hope to see some fun things happening there.
Next up, we have a new segment. This is “Ask Wordfence.” So I’ve been asking you, our podcast listeners, for questions and things that you would like us to address and one of our customers reached out and had a question about brute force. I thought, who would I talk to about better tightening a WordPress site using Wordfence and keeping sites protected from brute force attacks than our lead customer service engineer, Tim Cantrell.
If you’ve ever been to a WordCamp, I’m sure you’ve met Tim. Tim. Tim goes by “East Coast Kathy,” he is my counterpart on the East coast and I am “West Coast Tim” and we have shirts that say East Coast Kathy and West Coast Tim. And when we are both at a WordCamp, we laugh a lot. We have a great time. We laugh amongst ourselves, we laugh with customers. I have not had more laughter in my life than I have had being at a WordCamp with Tim Cantrell. So, here’s Tim.
Hi Tim. How you doing?
I’m great Kathy, how are you doing?
I am doing spectacularly. So I wanted to do a segment of the podcast, which is Ask Wordfence and I wanted our customers to ask them questions. We had one come in where a customer asked what settings in the Wordfence plugin they should use for brute force protection. Like for example, how many login attempts or password resets should they allow before they block an IP address. Do you have an answer?
I do happen to have an answer. Yeah, it’s a real-
Amazing. It’s a really good question, actually. There isn’t a hard or fast one size fits all kind of set of rules that work for every site. Really, how many login attempts or password resets you allow really depends on the type of site that you have and who’s actually going to be logging into it. If you’re the only person that has to log into your site, just like a simple site with one admin, then you probably you want to set that for a lower number, like three attempts and that’s a good place to start. If you have all kinds of users, maybe varying tech skill levels, you might want to actually give it a few extra tries over that. People may actually be like me and fat finger passwords and usernames all the time.
While it’s good to want to block the bad guys, if you’re also with the same time blocking your customers or your site visitors too because your rules are too tight, well then your visitors, your customers, your members they may just take their business elsewhere. Or you’re going to spend all day unlocking accounts and neither of which are fun or optimal. You kind of want to land somewhere in there in between.
I generally allow about 10 attempts at logging in before I lock out a user. And I usually set the lockout period for about 30 minutes. Most of the time if it’s a bot or a script just kind of doing a random attack on you, they won’t stick around if they get blocked enough. And since they change IP addresses often 30 minutes, to keep them blocked is probably enough.
Of course, if you’re seeing a lot of log in attempts from bogus sources because you’ve got one ongoing attack happening, you might want to lower the number of attempts. You may want to increase the amount that they’re locked out just for the duration of the attack.
The trick is really to be aware and to pay attention to the alerts you’re getting. You’re probably always going to have somebody that gets locked out at some point or another. But if you’re diligent in responding when there is a problem for a visitor or a customer or a member, they’re going to appreciate that your policies are there to make sure and keep the site safe for everyone. So I guess that’s kind of an answer.
Yeah, that sounds reasonable. So like if somebody is first getting started with Wordfence, would you suggest that they receive notifications of all lockouts just to get started so that they’re aware of what’s happening on the site so that they get emails when that happens?
You can, but I have a theory that it’s really easy to get lost. The more emails you get, the more alerts you get, it’s easy to kind of miss the trees for the forest.
So if you’re getting all these email alerts, and it’s great with our plugin, we want you to know that we’re doing our job. This is what we do. We want you to show you that things are happening. But the problem is that if you see them all the time, then you start to like miss things that you should probably be paying attention to. Like when scan alerts come in and there’s a problem, I want to be able to see that stuff front and center.
That makes sense. Cool.
I hope so.
And so do you think people should go blocking IP addresses when they start seeing malicious activity?
There’s two different schools of thoughts on that and I think a lot of people think that when they get those IP addresses that they need to block them right away. Let me add them to the block list. Like I kind of alluded to before, blocking IP addresses, probably not the good long-term security policy. And the reason for that is, is that again, like I said earlier, that these bots and scripts they get blocked for more than like 5 or 10 times, sometimes more than that, sometimes less, they’ll switch IP addresses. VPNs and proxies, it’s really easy to switch your IP fast and not be a problem there.
So blocking IP addresses, once those are released, the bot script or the hacker releases that IP address, well that can land in like an actual visitor. That could be an actual customer, after that. If you block their IP address and just walk away, well, you’ve locked somebody that may come and want to read what you’ve written and they may want to purchase something. So like long-term strategy, it’s not really a great idea to do that.
Plus pretty soon, you’ve blocked like hundreds and hundreds of IP addresses and then you have to manage all that. When do you go back and try to like go, and who’s been, and which IP addresses do I release now? So usually if you just want to set that for a time limit for however long you’re comfortable with, that’s the better strategy.
Sounds good. Sounds like you should just let Wordfence do its job, right?
Well, that’s what we make it that way for us so that it makes it easy for anybody to be able to secure their site without really having to understand all the ins and outs and ups and downs. Just let the plugin do its job.
Thank you, Tim. Hey, if I have more questions from customers, can I bring you on again?
Absolutely. I love being on your show. I’m so excited for this.
This is really awesome.
This is awesome. And people should go follow you on Twitter, right? What’s your handle?
Excellent. It’s excellent. What’s yours?
Oh, just KathyZant. I’m boring. No leet-talk.
Not for me. All right, Thanks Tim.
No problem at all. Thanks Kathy.
We hope that answered some of your questions about how to protect your site from brute force attacks using Wordfence. And we hope you learned a lot about WordPress, what’s happening in the ecosphere and also more about some of these plugin vulnerabilities that have been coming out of the woodwork. We’re doing our best to address these as they pop up. Our threat intelligence team, in our Slack channel for threat intel is just on fire lately. They are doing a bang up job protecting the WordPress community and we will keep you as informed as we can.
If you’re not on our mailing list, please do subscribe to that mailing list. We will send you out only alerts when a blog post is going live. Obviously you can follow the podcast and we will cover these, but can’t cover them as fast as we do with our WordPress site. So how do you like that? Yes, we use WordPress too and we use Wordfence too. And yes, I was a customer before I started working here.
So if you have a story you would like us to cover, please let us know. If you have a question about Wordfence and you’d like us to walk you through how to use the tool more effectively, you can let us know that too. If there is anything you want to tell us, we are open ears all the time, email@example.com or firstname.lastname@example.org to get me directly.
Please “like “this podcast, leave us a review on Apple Podcasts or wherever you are listening. If you have feedback, we love to hear it. If you have feedback on how to make things better for you, that’s what we’re here for. We’re here to serve you, the WordPress community, so thanks again. I am Kathy Zant. I am “KathyZant” on Facebook, on Twitter, on Instagram. And you can follow Wordfence at all of those social media accounts as well. We are Wordfence at Facebook, on Instagram and on Twitter.
Thank you again for listening and for all of your feedback and we will talk to you soon.