[00:00:00] Nathan Wrigley: Hello there. And welcome once again to the WP Builds podcast, you've reached episode number 338 in titled Calvin Alkin. On the state of WordPress security, plugins security, many series one of four. It was published on Thursday, the 17th of August. 2023. My name's Nathan Wrigley and a few bits of housekeeping just before we begin.
If you are into what WP Builds, do head to our subscribe page and sign up for our newsletter. That WP Builds.com forward slash subscribe. Well, email you twice a week. Also to say that if you fancy making a comment, I'd really appreciate it. If you felt like going to the WP Builds.com website. Finding the particular episode and making the comment there. So for example, If you get something out of today's episode, this is 3 3 8 episode 338. Head to the website, find the post and make a comment there often. I think we tend to do things on social media more these days. It's quite nice to have one of the things that WordPress is good at being used. So yeah, that would be a real plea from me.
Also, if you enjoy what we're doing, please head over to your platform of choice. Share it over there. Perhaps even give us a five star review on your podcast, player of choice, something like apple podcasts or Google podcasts. That would be really, really lovely.
The WP Builds podcast is brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting that includes free domain SSL and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. You can find out more by heading to go.me forward slash WP Builds once more, go.me forward slash WP Builds. And true sincere thanks to GoDaddy Pro for that ongoing continued support of the WP Builds podcast.
Right. What have we got for you today? Well, this is something a little bit interesting and a little bit different, and I'm going to put a few caveats in before I begin the podcast properly. Today, we have Calvin Alkin he's from a security company called Snicco. And as you'll hear in the podcast, there's been a few bits and pieces going on in the WordPress security space recently.
Notably some of the research that Calvin has done has revealed possible problems with a variety of different security implementations, different plugins, different services, and so on. And so on the podcast today, he states his piece. Now in the whole social media kerfuffle that blew up around this. There was lots of people posting in different directions, having different opinions. It got a little bit heated. And so what I decided to do was put together a mini podcast series, and this is the first of four episodes I'm interviewing Calvin Alkin from Snicco. Akshat Choudhary from Malcare. Dan Knauss from iThemes, which is now SolidWP. And Thomas J Raef from We Watch Your Website.
I'm recording all of those because I think it'd be really interesting to have an equanimous look at this. To look at it from both sides to let people have their opinions, to let the product owners say what they think in defense of what Calvin is saying today. And so I did something a little bit strange. I told all four of those people that I would record all four episodes before I released any one of them. The idea being that they wouldn't be able to have an opportunity to listen to what somebody said and then create their podcast episode with a little bit of expert knowledge from having listened to a different episode.
So that's what we did. So this is the first of those four. You're going to hear a lot about Calvin's position on WordPress security, why he thinks that certain implementations are broken and what you can do about that. Over the weeks to come, we will hear from the other three participants in this little mini series. And they're going to be put out in a completely random order, but they have already been recorded and stored away. So you're going to hear all sorts about security today. I hope that you enjoy it.
I am joined on the podcast today by Calvin Alkan. Hello, Calvin.
[00:04:43] Calvin Alkan: Hi, Nathan. How are you?
[00:04:44] Nathan Wrigley: Yeah, really good. Nice to connect with you.
We're going to talk a lot today about security. There's a lot of relevant time based stuff that's going to be in this episode, but also broadly, we're just going to talk about website security in general. So probably, given that this is a very technical subject, two things to say. Firstly, I will be out of my depth and so I'm relying on Calvin to, to help me through it.
I'm imagining the case for many of the listeners will be the same with them. We might get into the weeds and if I feel confused, I will ask you to help me out. But the other thing to say is given that this is a technical subject. It would be important to know that you know what you're talking about. So Calvin, can you just give us a little bit of a backstory of your life?
How come that you've ended up on a WordPress podcast talking about security? Who do you work for? What's your background in technology and security in general?
[00:05:39] Calvin Alkan: Sure. I'm the founder of the company called snicco. We are a security company from Germany. We publish in depth research in security in the WordPress space. And we have a security product called Fortress that we sell to primarily WordPress hosting companies. Our background is, we started out like many actually doing client development like three or four years ago.
And we gradually more and more. How do you say develop into a product company, if that makes sense.
[00:06:14] Nathan Wrigley: Did you did you intend to go in that direction? You mentioned that you're selling primarily to hosting companies. Obviously the majority of people listening to this podcast won't be working. For a hosting company. So we'll be familiar with a range of products adjacent to WordPress, related to WordPress.
They might be plugins or some SaaS based product or something like that. Do you know if that's a, is that an industry which is fairly normal selling directly to hosting companies or are you a bit of a pioneer in that space?
[00:06:45] Calvin Alkan: No I'm, we're not a pioneer at all in that space. There are, of course hosting companies use like a wide array of software. But the first one to really sell WordPress specific software was probably Till from ObjectCachePro. This is now the WordPress caching plugin that many hosting companies are integrating now with service side to provide like better performance for all of their customer sites, basically.
So now we are, we're not innovative in that way, but there are still very few products in the WordPress space that are sold primarily to hosting companies instead of through the end
[00:07:24] Nathan Wrigley: Yeah, it's interesting because the marketing endeavors of most of those companies are probably not pointing their adverts directly at somebody like me. So I'm not really receiving the information about those kinds of things. Obviously, if you're the CEO of a hosting company, I imagine you're going to be hearing from people like you much more.
So yeah, that's really interesting. Okay. Firstly, we've discovered that there's a whole range of security products, which are pointing themselves directly at hosting companies. That's one takeaway. Everybody listening to this podcast. Presumably has some relationship with WordPress. They're either building sites or they're working for an agency, maybe they're doing marketing, but WordPress is the focal point.
And we all have a basic understanding that WordPress websites and indeed any website, any property on the internet needs to be secure, this is. Shifting sand. It feels to me like the conversation that we would have had six months ago is probably not the conversation that we would need to have today. And the conversation that we would have today will not be the conversation that we'd have in a year's time.
Because it's a constantly moving thing. The jigsaw pieces are just different every time you look at the board. So where are we at? At this moment, we're recording this towards the end of July in 2023. Let's talk about the state of WordPress security. I know that's a bit of a bland question, but just run us through some of the main things.
And what I'll do is I will link to a blog post, which is, was actually published in 2022, but I think it's still relevant. It's called the state of WordPress security in 2022. You'll find it in the show notes. It's on the snicco. io website. Just run us through what you were thinking there.
[00:09:06] Calvin Alkan: Correct. This is yeah, as you said, it was it was actually published in April 2023, or I think so. It was published in 2023, but the research that the article is based on was collected at the end of 2022. So what we did there is we analyzed a lot of WordPress security plugins or plugins in the WordPress security space or adjacent to the security space.
And focused basically on one aspect of security. We focused mainly on two factor authentication. And we found that many plugins, like from the most popular ones, like the, all the way to the top 50, if that makes sense. Yeah. They all had a very poor implementation of two factor authentication.
That in many cases, given some preconditions that we'll talk about later, even allowed taking over the entire site through that same two factor authentication functionality. So we contacted all of these vendors and responsibly disclosed our findings with them and help them fix their vulnerabilities.
And this article there basically highlights our experience or findings in the interactions we had With the vendors, which in some cases were really pleasant, but the majority was not great at all. So people taking way too long to fix vulnerabilities hiding it from their changelogs, not mentioning it to their users that they have to take certain actions.
So it was not it was not a good look, if that makes sense in, in general. So the, I guess the security companies or security products in WordPress, In my opinion, they have to be upheld to the highest standard. Yeah. So if security companies are not handling these things correctly, like how can we expect normal, let's say normal plugin companies to do things better if even at the security companies don't handle these things correctly.
Yeah, you can read the article it's very in depth, like all the vulnerabilities there are published on the website, they have all been responsibly disclosed, which is why there's like the huge delay between time of publication and when the data or all of that basically went down.
So it was like half a year or so that we gave people then time to update basically, because many companies, as I said, they didn't like correctly disclose these types of things.
[00:11:41] Nathan Wrigley: Can I ask you some sort of technical details about two factor authentication? I think most people will have an understanding that two factor authentication is basically adding a further layer. Usually something that you have. Not necessarily something that you know, so it might be a sort of time based code.
I think a lot of us will be familiar with something like that. So you go to a website, you are asked to log in, you type in your username and password, but then rather than being logged in, at that point, something else is required. I think the most common implementation would be something like an authenticator app on your phone, and you have to...
Type in a six digit code or something like that, which is time based and goes out every 30 seconds and, and all of that, but what really is going on there? In other words what have the platforms done? Let's say that I'm the owner of a plugin, which offers two factor authentication. What am I really doing?
What's the layer that I'm adding, or what's the layer that I'm subverting in the login process? And how is it that you can exploit? vulnerabilities in 2FA to, let's say, gain admin access, which is probably the worst kind of access you could imagine.
[00:12:54] Calvin Alkan: You explained that correctly. After you log in, you're typically presented with a new page or a new form, at least, in the UI. So what happens, the critical point and the most vulnerable point in this two factor authentication scheme is that after you log in, you basically need to store somewhere which person just tried to log in.
So that you can then, after the two factor authentication is successful, log in the correct person. So you need to somewhere persist that information. And if that is not handled securely, in many cases you could leverage that mechanism to trick plugins into logging in different users, or even not having to provide the first factor authentication at all.
So this is like the most vulnerable point. And every plugin basically has this point. It's not that they're all vulnerable, but at some point, everybody needs to persist which user just tried to log in to then, in the next request, after they complete the two factor authentication, then log in the correct
[00:13:56] Nathan Wrigley: Okay, can I just ask a question there? So that process, if you want to have 2FA, you not have that step. You have to have some mechanism of storing temporarily for presumably a very short amount of time. Who has just tried to log in? There is no way of achieving. 2FA without that process taking place.
Right?
[00:14:19] Calvin Alkan: There is, but it comes with some UX complications. For example you could do it in a way where you submit the login request and the Two of a code in the same request, if you will. So instead of just logging with your username and password, you also provide the six digit code, like all in one go and it's all validated in one go.
So some people have, it's possible, but it's not common. It's not basically nobody has done that.
[00:14:47] Nathan Wrigley: Is that simply because the UX is typically more straightforward from a user logging in the, you want to be done with the username and password step, and then you want to move on to the 2FA step. So the two things are separated just so that you've got some understanding. Okay. We got your username and password.
That bit's. Don, we're now on the 2FA bit, whereas if you had all those three fields, username, password, 2FA field, all on the one page, I guess you'd have to enter them all again. If it failed.
[00:15:17] Calvin Alkan: That's correct. And it's also some compatibility issue. For example, if you imagine in WordPress, there are probably a million different ways people are building login pages. Custom, the default one, page builder based, using their form plugin. And of course 2FA is not really useful if it's only applied to some login forms, yeah.
So it's very hard to make it compatible with many login forms if you try to basically enforce that all in one request, as I mentioned, because you can't really control the UI of other plugins, if that makes
[00:15:52] Nathan Wrigley: Okay. Thank you. That was great. Yeah. Anyway, sorry. I interrupted. Keep going.
[00:15:56] Calvin Alkan: So, um, Yeah, this is like the vulnerable point in, in, in pretty much every two factor implementation that we looked at and all of them in some way were vulnerable to some sort of vulnerability. So now we have to mention it. Many of these to be exploitable required a precondition to be present on that site.
And this is where like we sparked like a big controversy basically in the WordPress security space is because many of these vulnerabilities to be exploitable required that your site or that an attacker is able to read from the database in some way or form. Which is because all of these plugins were storing your two factor secrets.
So the way that it works, a really simple explanation your two factor application, so your Google Authenticator and your WordPress site. Typically share a secret, they both have the same secret that they share. And then that way they're both able to generate for a given timestamp.
They're both able to generate the same six digits. If you don't have the same secret. The six digits will never match. So this is highly sensitive data. And what most, or basically everybody was doing, is storing these secrets as plain text in the WordPress database. If an attacker can read this, an attacker can always generate the valid six digit keys for any given user basically.
[00:17:33] Nathan Wrigley: Oh, okay. Okay. So I'm learning some new things here. This is really interesting. So the 2FA plugin, in order to be able to, if you like, let's just say the word handshake. With your 2FA app, there needs to be some shared secret so that there can be a match made. Okay, the website has the shared secret, the app that you're getting the six digit code from on your phone, that has the shared secret.
And so when the code is typed in, there's a comparison made between those two shared things. And if there's a match, We're good to go. And if there isn't a match, something has gone wrong. But if I've understood correctly, what you're saying is that in the cases that you found that shared secret was in plain text, i.
e. not in any way hashed or encrypted, just what it is what it is. You could copy and paste that from the database anywhere you like, and that's the problem. And that. doesn't change. So the fact that your six digit code is changing every 30 seconds doesn't mean that there's anything changing in the database because that's just a code some plain text, which is the same today as it will be tomorrow, as it will be
[00:18:49] Calvin Alkan: Until you change it, correct?
[00:18:51] Nathan Wrigley: Got it. Okay. So there in lies the problem.
[00:18:54] Calvin Alkan: This is the main problem, correct? And then the controversy is, yes, you can't exploit it if somebody cannot read from your database but then it's, you have to consider the unique circumstances of WordPress Yeah many WordPress sites have vulnerabilities In fact, it's not like a matter of If it's a matter of when your WordPress site has a vulnerability at some point.
Yeah. So I have some stats here. For example the way the most common way you could exploit it is through an SQL injection vulnerability. What that allows you is basically to, because either your WordPress core or a plugin or a seam of yours has a vulnerability. That allows an attacker to basically read arbitrary data from the database.
Note, they are not able to change anything. That is a much higher severity issue. They're only able to read data. Yeah? Which is, for example, one of the reasons you hash passwords. If somebody can read all your passwords, you don't want them to be in plain text. And WordPress core obviously stores password hash.
There would be an outcry if they didn't. If that makes sense.
[00:20:08] Nathan Wrigley: but reading is enough in this case, right?
[00:20:10] Calvin Alkan: Reading is complete, is enough. You don't have to be able to write anything. In the last year, WordPress Core on its own had four SQL injection vulnerabilities in WordPress Core, not even counting plugins. If you had any of these plugins installed in the last year, and obviously WordPress Core as well, you would in theory have been vulnerable.
So we're not saying that this has been exploited, we were probably the first to find it, but you can never be sure, can you? And then just go into the, in whatever, patchstacks database, the database of WPSCAN, the database of WordFence, and just count how many of these are how many of these SQL injection vulnerabilities are added on an almost daily basis.
So almost every single day. There's like an SQL injection vulnerability in some plugin with huge install numbers as well. So it's not a matter of if this is possible. It's a matter of when is it possible to exploit this? And all the plugin vendors basically told us, yeah, we, this is not really a vulnerability because you can't exploit it on its own.
And yes, this is true, but you can't really you're not developing in a vacuum, are you? You're developing for a WordPress site that probably has 25 other plugins installed. So it's not it is wrong and it's very harmful to view it that way. If that makes sense.
[00:21:42] Nathan Wrigley: Yeah, I'm just going to rewind and just explain where I'm at so far. And if I've understood correctly. You discovered that two FAs were being stored in plain text. You further dis That then led you to go to some of these security vendors and say, look, you've got a problem here.
Yes. We understand that it would require another vulnerability, some SQL injection, or maybe there's other scenarios that you can describe as well but for now, let's leave it there. If there's an SQL injection, it basically. You can make a stack here. You get the SQL injection, you start reading the database, you discover that plain text key, and then you're off to the races, and all sorts of other damage is done.
So you went to the vendors, and they said, this is the way it's done elsewhere, it's not for us to think too much about the fact that Other plugins could be vulnerable. That's not really where we need to be focusing our concerns. I'm sure that's probably oversimplifying it, but is that broadly what you were saying?
[00:22:48] Calvin Alkan: That is a very accurate description, yes.
[00:22:52] Nathan Wrigley: Okay. I'm up to speed. I'm still with you.
[00:22:55] Calvin Alkan: And yeah, we like ultimately every single one of these vendors fixed it. So to every single vendor, we sent them like our proposed patch. So look, this is how you should be fixing this. And ultimately every single one of them. in some way or form implemented our proposed patches. And like we, it's the stats are in the blog post.
I don't recall exactly, but if you add all of these up, it was like 16 million installs across all of these plugins. So it was literally from the most popular ones down to like more niche 2FA plugins, but they all in some way did this. And then. Rather sooner or later implemented our proposed patches.
So this is also why it took so long to publish this research, basically, because obviously, like we responsibly disclosed all of these things. We didn't want to drop it without people having received patches, if that makes sense.
[00:23:52] Nathan Wrigley: Can we just talk about a couple of things? So the first thing, could you explain to people listening, what is responsible disclosure, just outline what that means and what the window is typically.
[00:24:04] Calvin Alkan: of course, a security researcher find a vulnerability. You don't go and publicly post about it yet because attackers will start abusing it. So you go either through a platform like PatchStack or WPScan, which will handle the disclosure coordination with the vendor for you, but you can also just directly contact the vendor and help them figure things out, help them fix it, not necessarily, it's also okay to just send them what you found.
And they'll fix it and once you, once the vendor fixed it, then you can publicly talk about or publish your research or whatever, but not until they fixed it. So the typical window is I think it depends on whether the vendor responds or not, but I think patch tech, I might be wrong, but patch tech, I think is doing 14 days.
If you acknowledge it was in 40 days, you have another 30 or so to fix it. Like this is typically like some variation of this, but we gave them like a huge amount of time. This was half a year basically.
[00:25:08] Nathan Wrigley: Yeah. Okay. So responsible disclosure is the process of just going to the vendor directly and not trying to sell it on the black market somewhere or just, exploit it yourself is to just give the vendor a window of opportunity in which time they can hopefully fix it. Okay. That then leads me to the next question, which is what Can you describe what the fix was?
How did you turn a plain text string of, let's say it's numbers and letters and characters and what have you, what was the fix? What was, I mean you don't need to go too technical, but was it just hashing that or?
[00:25:47] Calvin Alkan: In this particular case, you can't hash the secret because hashing is not reversible.
[00:25:53] Nathan Wrigley: thank you.
[00:25:54] Calvin Alkan: And for the two factor validation to work, you need access to the, you need access to the plaintext secret, but you don't want to store it as plaintext. So hashing is not an option here. What you have to do is encryption.
Encryption is reversible. It is a pretty easy fix, which is why it's surprising that vendors were so reluctant to implement it, because it's really not that complicated. It's maybe 50 lines of code or 20 lines of code overall, like you could reasonably, if you want, if you include automatic upgrade migration for the users, like you could be doing it maybe in two days a week, maybe maximum.
It's not really that complicated. So you just, in, instead of storing the secret as plain text, you store the secret encrypted in the database and then you store the encryption key used to encrypt the secret. You store that elsewhere. Securely, for example, in the wp config file, there are better options, but to achieve browser compatibility, storing it in the wp config file is the best option.
It's not ideal, but we don't have to go into that. But the important thing is, which of course also many vendors then failed to implement this, what they did, they encrypted it. Yes. But then they encryption key. In the database, which is
[00:27:14] Nathan Wrigley: Oh, okay.
[00:27:14] Calvin Alkan: correct. Which you can also then as an attacker read, and then you can decrypt it locally.
Which, which, these are things which, which makes you wonder, you should know these things in a security company. If you encrypt something, if you store the encryption key right next to the encrypted data, like there's no point really. It's for example, imagine you have a vault. Yeah.
And the vault has like a lock combination that is
[00:27:41] Nathan Wrigley: on the front.
[00:27:42] Calvin Alkan: correct. That is like putting your whatever, your gold bars into the vault and then having the sticky note with the combination, on top of the vault. This is basically what many vendors implement then as their proposed patch.
And then we had a follow up look, this is still not fixed. You have to do it. It was like a very tedious process. And as you mentioned previously, there was like a lot of finger pointing going on Yeah, hey, but nobody else does it, and then we had to explain, yeah, look, everybody else has the same vulnerability, everybody else is in the process of fixing it.
It's, it was not a very good experience.
[00:28:16] Nathan Wrigley: It's really interesting. I got a letter through the post, the physical post the other day, and it was to log on to some aspect of the council that, that I, where I need to pay my tax and things like that. And it just. I was hit really hard in the face by this letter because not only did it contain my username, which was just a garbled string of nonsense, but it also underneath it contained the password, which is also a garbled string of nonsense.
And I just thought that's great, isn't it? If the postman decided to open my letter, that's the end of that. So there's a real world example of how silly that can be. But also, my understanding is that if you, for example, were to attend some of these hacker festivals, like Pwn2Own and things like that, isn't it common practice not to just be doing, trying to attack through one vector?
Isn't the endeavor at those things to be able to... To layer things on top of each other. So you're exploiting some vulnerability in Chrome, which then leads you to another vulnerability in some other part, which then finally allows you to get into the root of the iPhone or whatever it may be. In other words, it's fairly typical in the security space to have these layered attacks where you gain a little bit of a foothold by doing one thing, and then you penetrate a bit more and go a bit deeper.
And in some cases you've got many layers. to this cake before you finally get to, to do what it is that you want to do.
[00:29:47] Calvin Alkan: No you're absolutely correct. But unfortunately, like this belief or this knowledge apparently is not widespread in the WordPress security ecosystem. If somebody can read from your database, yes, that is a vulnerability. Yes, it's not good. All your maybe sensitive data. If you have sensitive data, you should have encrypted it in the first place.
But all of your database can be, is leaked now. But I should never allow you. Or allow an attacker to leverage that into compromising your entire site. It's you're giving up at the first resistance, if that makes sense, from a security standpoint. Does that make sense, what I'm trying to say? Re got given up. It's that's not our fault.
[00:30:33] Nathan Wrigley: You
[00:30:34] Calvin Alkan: Re, like at the first point where it becomes complicated, it's yeah, hey, this is you already have a vulnerability, this is not really our problem anymore.
And this is a very Harmful way to think if you're a security company, because if you do it as a security company, like what can we expect from product companies that are not even security companies, if that makes
[00:30:56] Nathan Wrigley: Yeah. Yeah.
[00:30:57] Calvin Alkan: So you should never be able to leverage being able to read from the database into.
hijacking this entire site or server that should never happen.
[00:31:06] Nathan Wrigley: Yeah okay, I've got a couple of things to say here. The first one is that because this created such a storm around the WordPress space. If you don't know anything about the storm that was created, there was a storm. Lots of people were, getting into social media and explaining their point of view and why they, why they had this side or that side and what have you.
And that prompted me to call people like Calvin onto the show, but also I've got a couple of others lined up and. Those other ones that are lined up will perhaps have a different point of view. And for the first time ever, I've got this little kind of mini series of podcasts, and I'm gonna isolate them from each other so that nobody knows what anybody else has said, just to keep things fair.
There's that. If we get into something in this episode which you think hang on a minute, where's their voice in this? That's coming. Hopefully hopefully at some point they'll get to say their piece. So trying to maintain fairness, trying to maintain some sort of equanimity in all of this but okay.
So you went to some of these vendors and as far as you could tell, they basically did. Didn't do anything. They just said it's not our problem. And then when they did do things, it was probably not sufficient.
[00:32:25] Calvin Alkan: Um, Yeah it's a combination of it's, it started from have us having to send very sensitive vulnerability details. So their support chat. Yeah. Because we asked them to like, and we have all the stats, they are in the article. I don't recall like exactly, but out of all the companies that we contacted, I think one.
Had a public encryption key that we could use to actually encrypt the vulnerability report before sending it to them, because you don't want maybe on authorized support staff to be able to read these vulnerabilities. And it's like using third party software, third party chat software, like who knows where that data is stored?
Who knows who's able to read that? These are basic principles that should be like a given, not even for security companies, for any product company. Yeah. So it's like from top down, it was like the horrible, basically. And then we basically refused to send these things explicitly through their support stuff.
We asked them for, Hey guys, this is sensitive data. Do you have maybe a security email or maybe like, how can we reach out to your lead developer or whatever it is? Yeah. And no, like we were forced to send vulnerabilities. Through third party chat software, basically, and then sometimes we got like a fast response and actually if you click through the blog article, like all of these things are published there, like for each vendor, we have the exact timeline, how that all played out, we highlighted when they did stuff great, we highlighted stuff that we didn't like, but it's all very neutral, like all basically explaining how it happened.
Then many vendors took like weeks to even come back to us. That this is this should have been fixed in days, but we first received a reply from them in weeks. And then the first interactions were usually like some form of denying that this is even an issue.
And then us having to convince them that, Hey, yeah, everybody else is doing it also, but that doesn't mean that it's right. Yeah. The, if that makes sense. And yeah, it was It was a very unpleasant experience and then after people ultimately fixed it in some way or form to the way that we recommended that we actually validated most of the patches as well.
Then they basically hid it from the changelog. So they didn't, and this is really important. Once you release a security update, you have to have that cleared security update because otherwise you're only giving attackers. An advantage over your legitimate users because hackers are actively monitoring what happens on the WordPress.
org repository. They're actively checking changelogs, checking diffs of the updates and whatever. And if you don't have it clear in your changelogs, or even better, send out an email to your users, tell them what to do. Hey, update this ASAP. You have to do X, Y, and Z steps. Maybe reset your password.
Yeah, maybe set up your 2FA credentials again for sensitive admin accounts because we don't know if it has been compromised. It might, probably not, but who knows, yeah? It was like on every layer basically. It was very, a very bad look. And
uh,
[00:35:41] Nathan Wrigley: kind of Interesting by pure coincidence. I got an email today from a WordPress plugin vendor who we won't go into names, but they have fallen foul of a vulnerability in another. piece of infrastructure. It's not as plugin as such, but I got this email today and it literally said exactly what you've just said.
It was all about, okay, this is what we've done. It's mended. But now here's a bunch of things that we recommend that you do in order to get back up and running. So it said here's how to get into your dashboard. Check that this is the number of the plugin that you've got installed.
If not install. Install it immediately. And then you might want to think about resetting certain things and so on and so forth. So that was interesting. And by pure coincidence that dropped in my email inbox, and
[00:36:31] Calvin Alkan: Yeah, no, you're right.
[00:36:32] Nathan Wrigley: nothing to do with the subject at hand, but
[00:36:35] Calvin Alkan: No, I don't think so. This is like a month back, but yeah. And then even after that, after public, like some vendors, try to publicly discredit us in a way that this is a mean. So this was a literal quote. This is a mean attack. So like we'd sent like really like elaborate text on what the vulnerability is, how it can be exploited.
How it can be fixed. We even for free help the vendors to fix it and validate their patches. But in their eyes, it was for some of them. We also have to be fair. There was some companies that were really pleasant to work with and they fixed it really fast. But they are like a huge minority, if that makes sense.
And some vendors even went as far as saying like this is a mean attack from our part or implying like malicious motives from our end, yeah. So this is it's not good. And the main argument is hey, why do these vulnerabilities, these are not actually vulnerabilities because they don't have a CVE, if that makes sense.
[00:37:36] Nathan Wrigley: Okay. So we're going to need to explain what that is.
[00:37:38] Calvin Alkan: Right, So when...
[00:37:40] Nathan Wrigley: Yeah.
[00:37:41] Calvin Alkan: When you have companies like PatchDeck or WPScan, they always provide in their database like the 10 out of 10 rating. I'm sure you're familiar with that, yeah. So this is the CVE score. The point is, the CVE score by design does not allow anything that has a precondition, no matter how common that precondition is.
So the fact that our, call it security neglects if you want. We can't report them through the CVE system because they require some precondition, being in this case the SQL injection or anything else. So you can't assign a CVE. That doesn't make it any bit better though. And this is like a flaw in the system a bit because in WordPress you're not developing in a vacuum.
So it is very yes in Siri if you install WordPress Core in your plugin. It might not be exploitable, but if you install WordPress core, your plugin, and then 25 other plugins that might never get updates by the end user, yes, this is a real probability. And this has been our issue I'm actually...
[00:38:49] Nathan Wrigley: That is a curious that is a curious loophole, isn't it, in the CVE scoring, that if it requires another vulnerability to leverage it, it can't have its own unique identifier, if you like. Okay, that's fascinating.
[00:39:04] Calvin Alkan: What is a great thing that has been happening now is that we work a lot with patch tech. We communicate a lot with them and they are now considering based on our research to add the name is not like fixed, but it's something like community advisory database. Where these things then can actually be published even though they are not like assignable with CVE that people can actually know these things and that it shows up in the reports and in their API calls and whatever So this is like a development that I'm really happy about because it will actually make it possible to properly report these things So that the end users of these products will also know about it.
So this is like a very recent It's not public yet or anything But it's something I'm really happy about that is now happening or being speaked
[00:39:51] Nathan Wrigley: Yeah, so Patchstack and a variety of other vendors in the WordPress space, they are given the right because of their heritage and their diligence over many years doing this kind of work. They have earned the right to assign these CVE scores, but they must abide by the rules. And so what they're then doing is they're creating their own kind of subset of.
Not the rules because they're obviously outside of that slightly, but they've got a new tag, if you like, there's a new thing that we can say, okay, this is a thing, it's not the CVE thing, but it's still a thing.
[00:40:27] Calvin Alkan: Call it there's no solid, concrete thoughts about naming it, but call it, I don't know, security neglect or whatever.
[00:40:34] Nathan Wrigley: Yeah. Okay. Yeah. Oh, that is interesting. That's a nice, that's a positive. We've got something positive.
[00:40:40] Calvin Alkan: Yeah, this is something I'm very happy about. I think we WordPress security research that we published.
[00:40:47] Nathan Wrigley: That's lovely. That was a really, that was really helpful. I'm sure that everybody listening to that will have got a real solid understanding. We're going to carry on talking about WordPress though, because there's so many people using WordPress 42, 43% of the websites and all of that, all of those big statistics, lots and lots of websites.
But obviously a lot of us are not really Qualified to do the security thing. And a lot of us have probably tasked with doing the website. So we've got to make the buying decisions and we're the ones getting the plugins. And so that's strange, at the enterprise level, presumably you're hiring people to do all of this.
And you've got a great expectation that they've got deep understanding of how their internal security works and the layers of it and all of this. But on the WordPress side, it's there's more freelancers. There's more people who are just. building their own mom and pop store and all of that. So let's get into that.
The fact that non technical users have got to make decisions about security and the problems that causes.
[00:41:47] Calvin Alkan: Um, Yes, this is in our opinion, like a huge problem in WordPress that non technical users are buying security products as if it were just any other product, but end users can't really judge if it's actually secure. So if you buy, let's say your forms plugin as an end user, yeah. You can use it, you can see if you like the UI, the form submits, you get your data entries, your email notifications work.
Yeah, you can judge, you can't judge if it's secure, but you can judge that it is working correctly as it
[00:42:20] Nathan Wrigley: functions.
[00:42:21] Calvin Alkan: It functions, yeah, that's the word I'm looking for, it functions. With security products, yes, they might function. So your 2FA codes are working, you get your email notifications, your passwordless locking is working, yes.
But you have no way of assessing or knowing if these underlying protocols are actually being implemented securely. You don't know. There's a very few percentage of of people in WordPress that can actually assess these things. It's very it's a huge problem because then people like they are, they feel secure.
So they feel like they're already doing something. Or in effect, they're not. So they're, they have security products, but they're not being made more secure by using them, if that makes sense. So this is a huge problem. And one recent example that I thought we, we should get to was like this huge huge Mallcare controversy that we published.
Where we reported the vulnerability with Mallcare, and maybe you want to recap Mallcare as They have Mallcare WP Remote BlockVault. It's all basically the same thing under the same company, it's just with a different name. In all of these products, we disclosed the vulnerability with Mallcare.
And it wasn't fixed for 90 days. And then after that, we publicly published it. And it was like there was like recently, like maybe one or two weeks ago, from the point where we're recording now. And it was not a very good look because to explain what happened in simple terms, Malkar or all of the, like when I say Malkar, like think of all of their products, they're basically the same thing.
So Malkar has like a local plugin and then they have a remote application that talks to your local plugin on your local WordPress site. And obviously this communication in some way has to be secured so that nobody can impersonate Malkar. If that makes
[00:44:23] Nathan Wrigley: Yeah,
yeah,
[00:44:24] Calvin Alkan: for that, you all, you typically use API keys or API tokens.
And what happened in this case, again, was in the same way with the two of a stuff is this API token was stored in plain text in the WordPress database. So if anybody can read this token, that's all they need to completely impersonate more care. From the perspective of your WordPress site and it gives them the capability to, to do anything that mall care can, which unfortunately are a lot of very sensitive things like adding new users uploading plugins, installing arbitrary files from anywhere on the internet.
So if that secure communication is broken and somebody can impersonate more more more aware of what I'm saying, mall care, like your site is completely hacked. Yeah, and it can this is basically a vulnerability. We don't have to go into all the technical details. We have that published on our site and we will link to it in the show notes,
[00:45:28] Nathan Wrigley: yeah,
[00:45:29] Calvin Alkan: but this is how it went down. Again, this is another example of you can't exploit it by default. But we had like a qualified intro directly to Marker CO and we disclosed this as always in extreme detail. We even sent them like a full running proof of concept where you just type okay, run proof of concept, if that makes sense.
And then you can see actually that a malicious administrator has been added to the site. And again, we, the response was like, yeah, but this is I don't want to disclose all of this, but our response was very much the same that we got previously with the 2FA stuff. Yet it doesn't really matter because you can't exploit it by default.
You need another vulnerability to be able to get the secret. And pretty much like the, how to say the impression that we got was, yeah, look we're not going to fix this or at least not in any urgent manner. Yeah. And they didn't. So 90 day passed and then we publicly published it, the vulnerability and yeah.
So Yeah. So to add to that, they basically told us, yeah, Hey, it doesn't matter because you have a vulnerability, but this case is a bit unique in that mall care is a malware scanner, right? So bear with me here, the malware scanners main usage, they also have some other functionality, but the main thing is that they are providing malware scanning.
If you have malware on your site, that's by definition, the only time you need a malware scanner. If your site can never, ever be infected with malware. Don't need a malware scanner, right? That does make sense, correct? And also then, add that to that, if you have malware on your site, by definition, it can read from your database.
What actually could have happened if some if an attacker that's performing large scale hacking of WordPress sites, what they could have done is, they could have checked, hey, is this a malware site? If yes, like we just extracted the API token, all of the database and send that off to our remote server to store it just for now, store it.
And then they delete the malware. So they stole your secret key and deleted the malware. So there's no trace of a hack happening at all. Yeah. And what they then do after, for example, let's say they're recently, there were a lot of vulnerabilities in WordPress, like in many popular plugins, Elementor, WooCommerce, whatever, instead of infecting your site and performing the malicious activity right away, they could have just sent off your market secret key.
And once all that noise has basically watered down, they can reinfect your site continuously through that. API key, and you will never be able to detect it because you don't have any vulnerable plugins anymore because it's not known. Yeah. And you have no malicious files. Also, there are no files.
Your sites have not been modified. But the attacker can continuously reinfect your site because they have that secret and to your site they are basically malware. So they can always install new administrators, they can always install malicious plugins. Anything that, that malware can do from their side basically.
So them saying, yeah, it doesn't really matter that, that because you require precondition. That doesn't make any sense in their specific case because their, the entire value of their product lies in the capability to effectively detect malware. And malware can always exploit this precondition because they can always read from your database.
Does that make sense?
[00:49:07] Nathan Wrigley: Yes. I'm going to rewind again. Firstly couple of things. The first one is did, did Malco in the end get a fix with you? Did that, did you manage to get to the point where this has now gone away?
[00:49:21] Calvin Alkan: This is now fixed. So the timeline is we disclosed it with them. 90 days passed. Then we disclosed it publicly. And for obvious reasons, many people were very upset with them. And then I think within one or two days after us having disclosed it publicly, they published their fix. So it's fixed now.
Yes.
[00:49:42] Nathan Wrigley: okay. So there's that. The second thing is as I mentioned earlier, I will be chatting with somebody from Malcare and they can obviously put their side. So keep an eye out for any mention of the word Malcare in our episode titles. And you can, hear that side of things as well, just for responsible disclosure, I'm just letting you know that we're going to try and see both sides of this. And also, I'm going to try and summarize what you've just said so that I'm clear that I know what's going on. Assuming that somebody has already gained access through some other side, some other channel, so an SQL injection or what have you, you could then use the, you could read the key.
Which the software puts in, which enables it to communicate with the home base, if you like, it's SaaS version of the product. And because that SaaS version of the product by def by definition, because of the nature of that product has. All sorts of privileges, creating users, deleting plugins, adding content, I don't really know. But there's lots and lots of privileges, but the attacker could then just obliterate all trace of itself and then just come back in a few weeks time and be undetected by the malware detection because the malware detection is looking for. Thing at the signals might be have any files changed.
Is there anything here which we're not expecting, but there wouldn't be any of that. All there is knowledge of that API key. Got it. Okay.
[00:51:16] Calvin Alkan: This is exactly the issue.
[00:51:18] Nathan Wrigley: Okay. Perfect. So yeah, so this then is a systemic thing in WordPress is WordPress doing something badly? Is it that we, or is it just the nature of CMSs?
You can't really get around this.
[00:51:32] Calvin Alkan: No. This is a WordPress thing. In their response to us, they mentioned that this is seen as a standard practice. In WordPress and also in other development ecosystems, which is, yes, there is a case in WordPress that is a standard practice, but as we already mentioned that doesn't make it any better.
And in any other software ecosystem, yeah, be it like Laravel or Symphony or whatever, if you were caught being storing like sensitive data, such as API tokens in plain text, there would be like a huge public outcry. This is absolutely not the standard way to do things. For the reasons that we mentioned.
And it's also to talk about basically how it all went down. There are justifications for taking 90 days. Whilst that is, yeah, it's authentication related and you can't make these changes like fast. Because you have to test everything and whatever. Which is true to a degree, but the fix is really not that complicated.
We sent we told them how to fix it. It's maybe in their fix that they shipped after 90 days, it's maybe I haven't counted, but 50 lines of code. So you could do that in a day, probably maybe a week if you want to test really sorely. And we also have to mention that this was by pure accident.
So we were troubleshooting an issue a customer of us had with the WP Umbrella product, which is like also, if you don't know, WP Umbrella is like product also a SaaS version. That allows you to manage many WordPress sites from a central dashboard. Yeah, similar to MainVP, W ManageVP. And they had the same conceptual issue.
Their API token was also stored in plain text. It's the same conceptual issue, obviously not the implementation was different, but conceptually it was the same thing. The API token they used to communicate was stored in plain text. We disclosed it with them. They took that very serious and they fixed it in two days after us having contacted them and it's really not that complicated.
It's a very simple fix actually. So we're just like, I don't know. I don't know why they didn't fix it in 90 days. It's we can't really understand it.
[00:53:41] Nathan Wrigley: Is there anything that could be done on a. I don't really know where to pitch this, but is there anything that could be done on a, I don't know, requirements for plugins? Now, I know that in many cases these will be commercial plugins, so you might be downloading them directly from the vendor. But do you know if, for example, anything in the WordPress.
org repo... Has to jump through hoops to prove that they're not doing these kinds of things. I genuinely have no knowledge of how these kinds of things are scrutinized before they would get into the repo or whether there's any documentation around this kind of thing in the WordPress space.
[00:54:19] Calvin Alkan: right. I'm not like familiar with all the review processes, but I highly doubt that there's anything checking for these defense and that security practices. But this is like why I'm excited about what you mentioned earlier, that like patch tech in response to our research and our disclosures is now like in the process of setting up like a different type of database, a different type of category for these types of issues so that people actually know about these things and can find out about this, even if they're not like super technical.
And this is ultimately, I think, the only way that people are going to change. If it's, if it shows up on, on patch deck or WP scan as having like security neglects, yes, then people will change. Until then, there's really no incentive for people because, yeah, it doesn't look like they care based on Based on the mere facts that when disclosed, they don't really act in a way. But this is why I'm very excited about what PatchStack is doing there now.
[00:55:18] Nathan Wrigley: We're we're closing in on an hour. We were going to talk about the sort of layered approach that you could have to WordPress security. I think we should still do that. I was suggesting that maybe we'd have some more time for this, but I think we should just rip through that one quite quickly if we can, so that we've got enough time at the end to talk a little bit about.
Fortress and what that is as well. I don't know if I'm allowed to, but I might try to hotlink to an image. I don't know if I'm allowed to publish it, but in the shared show notes that we've got this sliced cheese, basically. It's like this seven layer, I think it is. Model of how security can be layered one on top of the other.
Not simple, but I guess the stack gets more and more in depth and more specific to WordPress as you go further down or up, if I can link to that
[00:56:07] Calvin Alkan: Yeah, you
[00:56:09] Nathan Wrigley: I'll hot link to it. Tell us about that.
[00:56:12] Calvin Alkan: It's from MindSize, a very respectable WordPress agency. No, it's public blog post. You can definitely link to it. Yes, we now talked a lot about what is wrong or basically some things that are going wrong in the WordPress security ecosystem. But from our point of view now I want to talk about what is actually what you could be doing or how you should be thinking about WordPress security.
And it's all layers and more layers.
[00:56:39] Nathan Wrigley: It's all layers, yeah.
[00:56:41] Calvin Alkan: everybody understands security when you tell them, Hey, look, we're doing, we're using this kind of software for. This kind of thing. They'll ask you, okay, but how are you protecting against this different thing? And it's completely different and can't be handled with their software.
So it's all layering. Yeah, and Mind size came up with a very great and easy to understand model Which is like Swiss cheese that has like a lot of holes in it. Yeah And if you stack on top like different blocks of Swiss cheese, yeah? Each of the blocks will have holes. And a hole in that sense would be like an attacker being able to pass through that layer.
But then the way you stack your blocks of Swiss cheese is that overall there are no holes in it. Does that make sense?
[00:57:34] Nathan Wrigley: so I'll explain that as well. So imagine that you've got seven squares of cheese. I love this.
[00:57:41] Calvin Alkan: It's really great,
[00:57:42] Nathan Wrigley: it's great. Seven squares of cheese, and Swiss cheese if you've ever looked at it, it's completely random. There's holes in all sorts of different places. So if you had seven slices of Swiss cheese, Each one of those slices would have a different conf layer sorry, a different selection of holes spread across its surface.
If you were to lay any two random slices together, some of those holes will collide. You might be able to stare through and poke your finger through, because it just so happens that they've got two things which match. But if you put three or four together, what are the chances of you being able to poke your finger through?
Because at some point, one of those layers... Will not have the hole at that exact point. So your finger will suddenly collide with that. That should be enough. Go and look at the picture on the WPBuilds website to explain it better. But yeah,
[00:58:29] Calvin Alkan: Yeah, no, this is it's this layering is like not a new concept, but they put it like into a super
[00:58:37] Nathan Wrigley: it's really easy.
[00:58:38] Calvin Alkan: digestible
[00:58:39] Nathan Wrigley: literally digestible. Ha.
[00:58:43] Calvin Alkan: so it talking through that yet starts off with physical security, which is something that is handled nowadays at the. Data center layer. Yeah. So no, no WordPress hosting company at least should have their own racks of servers in their basement anymore.
It's all handled maybe at AWS or Google cloud or whatever. And they make sure that nobody can go to your server and plug in like a USB stick, if you will. Yeah, this is physical security. Which is something that you don't have to worry about. This is your, is not even handled by your hosting company.
It's handled by the infrastructure provider at your hosting company is most likely be using. Yeah. Then you have network security, which is seeing CloudFlare or other CDN type of products that are in front of your server. Yes. I'd say let's walk through each layer briefly, and then we can say what should be done at each layer and what shouldn't be done at
[00:59:44] Nathan Wrigley: yeah. Sounds good.
[00:59:45] Calvin Alkan: So you have the network security, which is like your CloudFlare or CDN type of stuff. Which can handle certain aspects before they, your server is even being hit by the request. Then you have server level security, things like stuff that your hosting company handles. Maybe malware scanning, or stuff like fail to bun that is installed on your server, or firewalls specifically on your server.
The other part is file system security, which is also like similar to malware scanning. So you could, for example, secure ensure that your... Files on your on your server have not been tampered with, and even this is really advanced, but you can actually make, and we don't have to touch on it briefly, you can actually make your file system immutable by design.
That means that it can never be changed. And if you want to deploy a new version or make a new update of your WordPress site, you just basically whip all of the files and then install a set of new files. But nobody can in production change your WordPress site, which pretty much eliminates the most of the issues regarding malware, because if the files can't be changed, you can't install malware.
[01:00:55] Nathan Wrigley: Interesting.
[01:00:56] Calvin Alkan: Um, The next part is application and user security. I would actually put these two things like together, think about stuff that you can do inside of WordPress. So we now have the network layer before your server, you then have the server layer, which is before WordPress is being run.
Yes, and then inside of WordPress on the application or user layer, there are also some things that you can do from a secure perspective. And the last one is backup and recovery, which is something that is not talked about not talked enough about, which is, imagine the worst case, you are hacked and you don't have backups.
What do you do? And you're really screwed.
[01:01:41] Nathan Wrigley: If somebody's managed to get their finger down the first six layers or seven layers, gets to your backup layer, oh pray, pray that you've got something there. Yeah.
[01:01:50] Calvin Alkan: And this is probably going to be one of the next research. Topics that we will be doing is like the security of backups
[01:01:57] Nathan Wrigley: know what? I was just wondering about that because given everything that you've just described, the ability to erase backups, just, that's got to be next on the list, doesn't it?
[01:02:06] Calvin Alkan: Imagine you're hacked and you're using like your only source of backups as a backup plugin
Haven't checked but maybe The backup plugin allows to delete your backups Like what do you do if you get hacked and the attacker is really mean and also deletes all your
[01:02:22] Nathan Wrigley: I think many of them do actually because quite a few of them allow for
[01:02:26] Calvin Alkan: because it's easy.
Yeah, it's convenient.
[01:02:28] Nathan Wrigley: yeah yeah I, I want to push, I don't know, a backup to Google Drive or something like that, but I only want to keep 14 versions. The principle there must be that I can delete version 15 if I want to insert version 1.
Yeah. Ah, interesting. So there is a lot to think about there, isn't there?
[01:02:46] Calvin Alkan: correct and in WordPress typically What many WordPress plugins are doing, they're trying to protect against all of these layers in one solution. You have plugins, for example, that do like stuff like banning countries by IP, yeah?
That
[01:03:03] Nathan Wrigley: Mm hmm.
[01:03:03] Calvin Alkan: allow you to configure, hey, I don't want anybody from like halfway across the world to visit my site.
Okay, it might work. But it would work like orders of magnitude better at, for example not Cloudways, I'm sorry Cloudflare, right? So before it even hits your server, yeah, you can ban IPs and countries in Cloudflare. You don't need to do it in your WordPress plugin. That's one example. The other one, which was our last research piece, is that malware scanning from inside a plugin does fundamentally not work.
We don't have to touch about that. We can link it in the show notes, but I think you also covered it on previous like episodes. It doesn't work. So more west scanning would be something that in this model is on the server layer. So you can't do stuff that should belong in the server layer securely at the layer that is below that.
Does that make sense?
[01:03:56] Nathan Wrigley: Is it, yeah, is it fair to say there that it can work, but it can't be relied upon to work?
[01:04:03] Calvin Alkan: Correct. It is like an example. It's if and we published stats about how often this is compromised as well. From we watch your website with whom we partnered on this research. They have like huge amounts of stats on this because they monitor a lot of WordPress sites and servers. And for popular plugins like WordFence, that is plugin based scanner.
It was like 15% of times when you're hacked. And if WordPress installed, WordFence is tempered in a way that WordFence can't detect detect the malware anymore. So we're just like, in another way, it's like asking can you rely on a clock that 15% of the time tells you something completely wrong? Can you rely on that?
[01:04:43] Nathan Wrigley: So the principle here being that if it's running I feel I'm going to stray into areas where my level of expertise is not enough to explain it, but is it something like this? If it's using... PHP, which is what WordPress is using, if the malware is on the same layer as that, and it's also using PHP, what's to stop the malware interrupting whatever it is that the malware scanner or the security plugin is doing?
It's conceivable that you could have something which is... Getting in the way of a WordPress security plugin and just saying, Actually, we're just going to disable this functionality without you
[01:05:24] Calvin Alkan: Good. Yeah. Correct. And how they typically do it is they whitelist themselves. Because many of these plugins have an option to whitelist specific files, which is like something that should never exist in the first place. But yeah, so they then just whitelist themselves and then yeah, it doesn't, it's not detected anymore.
But let's not dive into it too deeply we have an entire series on that, it's called Malware Madness. We published that with WeWatchYourWebsite, GridPane, and PatchStack. And we link to it in show notes, it's like super
[01:05:54] Nathan Wrigley: We will,
[01:05:54] Calvin Alkan: and understandable as well. This is pretty much covered, yeah.
And then the last layer that we have here is the user security, which is like stuff like, Making sure that you have strong passwords, making sure that you're limiting brute force attacks, making sure that you have two factor authentication, making sure that you have secure sessions and all of these things.
And the important part here is that this can only be done at the WordPress layer. For example, you can't really implement two factor authentication in a server level functionality because You need access to WordPress, you need access to the WordPress user database, so this can only run in PHP. If you think about it, in the Swiss cheese model, a block of cheese that is like below another one, cannot effectively implement stuff that should be done at the higher layer.
It can be done, but not effectively and sometimes conceptually it's impossible. In the other direction, yeah, it is possible, but not for all things. You can do malware scanning at the server layer, you can also do it at the plugin layer, but for example, you can't do two factor authentication in a in a server level or in Cloudflare, yeah, you can't have two factor authentication in Cloudflare, it doesn't
[01:07:08] Nathan Wrigley: makes sense. Yeah, honestly, this image is really good, and if you actually spend a moment or two looking at it and Thinking about it, especially the direction of travel starts at the top with the physical security. And then it works right down to the back WordPressy stuff and the backup and recovery right at the bottom.
When you actually start to think about it like that, as this almost not quite, but mostly a one way street down, then yeah, that makes a lot of sense. And you get an understanding of what's possible and what's not possible. That's fascinating. Yeah. Really interesting.
[01:07:39] Calvin Alkan: And obviously this is a complex topic, which a lot of end users in WordPress will not be able to implement themselves, which is also like the second big problem that we see in WordPress security. is that many security products are really built for the lowest common denominator of hosting platforms.
So many security plugins try or security products for that matter, they try to be as broadly compatible as possible. Yeah, because that's like the biggest market share. So that they try to be able to run it on 1 shared hosting. They try to be able to run it on PHP 5. 7. Sorry, 5. 6. 5. 7 doesn't exist. This is a problem because you can make these compromises in let's say, normal, in quotes, plugins.
Yes? But if you do it in a security product, inevitably you will have to make compromises somewhere because you're catering to the lowest common denominator. You have to make compromises somewhere. That then directly decreases security by a huge amount. It's it's not linear at all, if that makes sense.
And the way we saw that is, for example, in the 2FA stuff, why did all the, like, why did all products store stuff in plain text? Because proper encryption in PHP is only available after version 7. 2, I think.
[01:09:07] Nathan Wrigley: Right. Oh, interesting.
[01:09:08] Calvin Alkan: And it's possible, but it's not that straightforward. And for another example, why is everything stored in the database?
Because the database is the lowest common denominator. The database is always there. It's just not possible to have a WordPress site without a database, is it? This is like where then, these small decisions that don't seem like they are matter, yeah? They turn out to be huge reliabilities in terms of security. And then, yeah, you also have the many companies that I call it like portfolio security. Yeah. What they do is they, the SOAR process is I don't know, there are probably hundreds of security products in WordPress. And I don't want to name like specific names, but the SOAR process is something like we already do forms and we have a page builder and we do some e commerce and security would be a nice fit.
Yeah. That would increase our market share. And. The thinking is yeah every developer can create a security product, but there's a very small percentage of developers that can create a secure security product. Does that make sense? You can't just, you can't just go from being a developer to being a developer of a security product.
It just doesn't work that
[01:10:26] Nathan Wrigley: Requires a
[01:10:26] Calvin Alkan: You need, yeah, you need, or at least you need like in house information security experience that can then guide your developers or at least review what they are doing. You can't just you can't just decide one day, yeah, hey, we have these three different products, like today we're going to do security.
It just doesn't work that way.
[01:10:44] Nathan Wrigley: Yeah. Okay. I feel we've covered a lot of ground there. But I do want to give you an opportunity right at the end to, to talk about something called fortress. I think you may have dropped that word in somewhere, but I don't think in any way that would have made it clear what fortress is. Tell us about Fortress, who it's available to right now, what the roadmap is, all of that.
[01:11:06] Calvin Alkan: Correct. So Fortress is a security suite that we sell primarily to WordPress hosting company. And now it's great that we covered like the Swiss cheese model. Yeah. Before Fortress only does stuff that you can do best at the application slash user security layer. And because we primarily sell to hosting companies, this is like a great fit because hosting companies themselves can't.
By definition, implement anything at the WordPress layer. We only focus on application slash user security, which means stuff like two factor authentication sessions, password security, rate limiting, all of these things that you can do best and only at this layer in the model. And we do it for two reasons.
First of all Imagine you, and this is what happens a lot. If you have install like an all in one security plugin or product, you get like conflicts because the hosting that you're using might already be doing some of these things. So they might already have a firewall. Many actually do.
And your plugin is another firewall. And then you need to manage exclusions in two different places, for example. So at best, that causes feature duplication. And then degraded performance, and at worst, this causes conflicts. And the way we built this, it's not a plugin. It's, if you will imagine it like, it's 90% a PHP application.
And then you have 5% on top of it is like a WordPress layer, so that it can run in WordPress. And the remaining 5% is an integration that we built with each hosting company, so that it's deeply tailored to their, hosting stack. Every hosting company is running something different. Some have a firewall, some are based on, are running in containerized environments with Docker, some are using Nginx, some are using Apache.
So each of these companies get like a different integration layer which then greatly reduces the security that can be provided because, like we mentioned before, we don't have to make like assumptions that cater to the lowest common denominator in all these critical Decision area. So we know, hey, right now we're running at hosting company A.
So we do things like this because this is what works best at their hosting. And for other hosting companies, at hosting company B, we know what works best for them. But we don't have to cater to their intersection between hosting company A and B. Does that make
[01:13:47] Nathan Wrigley: Yeah, it makes perfect sense. I'm just wondering, do you have intellectual property around the franchise of this? So in other words, is it called Fortress wherever you go, or do you just silently go into the background and you're, I don't know, some sort of toggle, which you can switch on, but nobody might necessarily know it's what
[01:14:07] Calvin Alkan: Yeah,
[01:14:07] Nathan Wrigley: have done.
[01:14:08] Calvin Alkan: It is it depends on the deals we sign with hosting companies. It is completely white labeled, so you can see we completely white labeled it, if you have a license for that, yes.
[01:14:20] Nathan Wrigley: Yeah, and I know you've struck a deal with is it GridPane, I
[01:14:25] Calvin Alkan: Correct, correct.
[01:14:26] Nathan Wrigley: and GridPane are, they're they're in the WordPress hosting space specifically, but you've bolted on Fortress. Into grid pane, or is it that you can get it enabled? How does it work? A
[01:14:37] Calvin Alkan: yes, at the point of recording this GridPane is our first major hosting customer. And if you're a customer of GridPane you can install, so GridPane sells Fortis as an add on. to their services, and then they have a pre built integration where you can simply switch a toggle and it's configured and installed perfectly for GridPane's environment, their hosting environment, which is yeah, you get like all the security benefits, but you also don't have to do any of the integration work as an end customer, it's all handled for them and GridPane knows best.
How their environment works and you don't have to make the guesses about how to configure a security product for a hosting stack that you probably have no like idea how it all works in detail. Yeah.
[01:15:27] Nathan Wrigley: couple of follow up questions quickly, because we are stretching the amount of time here, I think. But quick couple of questions. The first one is, are you open to hosting companies outside of grid pane? Are you hoping
[01:15:39] Calvin Alkan: Yes. Yes. We are talking with several hosting
[01:15:42] Nathan Wrigley: Okay, so if you are listening to this and you happen to work for a hosting company, Calvin's email is open.
But also if you're, let's say you're working for a big agency and although you may not be handling you're not a hosting company, you may have a sizable clout with that hosting company. Is there any? Is there any mileage there? Are you looking for agencies? Because it feels like that's the level you're on.
You're not after end users like mom and pop building their WordPress site, but perhaps a large agency who has clout with a hosting company might be able to work with you. I don't know.
[01:16:15] Calvin Alkan: Yeah. Like you mentioned, our primary target is Hosting companies, because we think that is the best, the most user friendly and also the most secure way to give access to many people to Fortress. But we also sell in limited amount to agencies directly. It just depends on the use case. Yeah, if the agency, for example, should at least have one in house developer.
To be able to get that all up and running, it's not that complicated, but yeah, like you said we're not looking to sell like directly to a large market of end users. It just doesn't, it's, it doesn't make
[01:16:54] Nathan Wrigley: It yeah, you, from everything you've described, it makes perfect sense. And then last thing, you've got a, you've got a, an outreach newsletter where people can find updates about all of the different things that you're doing, new research and WP security topics being covered there. What's the what's the URL for that?
[01:17:12] Calvin Alkan: You can go to snicco. io slash WP builds. And then you can sign up for our newsletter there. We, yeah, so if you're not a customer of WordPen right now, and if you're not a big agency, the best thing you can really do is ask your hosting company to add an integration with Fortress. This is if several people do that, they are considering it.
[01:17:35] Nathan Wrigley: Nice.
[01:17:36] Calvin Alkan: And yeah, also to stay in the loop, like we publish a lot of previews or from our, because the research pieces that we write, they take like months. It's not like that it's done in a day, yeah. But we regularly send like preview snippets or updates basically to our newsletter. And yeah, if you want to stay in the loop that's a good way to, to do that.
[01:18:00] Nathan Wrigley: Perfect, thank you. Calvin, Alkan, really appreciate you chatting to us today. As I said, there'll be follow up episodes which hold a different side of the argument, but keep an eye out for those, but certainly really fascinating episode. Calvin, thank you so much for
[01:18:15] Calvin Alkan: Thanks so much. Thanks for having me.
[01:18:17] Nathan Wrigley: Well, I hope that you enjoyed that. Very nice chatting today with Calvin Alkin from Snicco. As I said at the top of the show, there will be three more episodes in this series, put out in a random order. Look out for episodes from Akshat Choudhary from Malcare. Dan Knauss from iThemes now, SolidWP and Thomas J Raef from We Watch Your Website. Hopefully over the course of those four episodes, Calvin's episode today included, you'll get some balance, some perspective, and you can make up your own mind based upon what all four of those people who said.
I hope that you appreciate the fact that I'm doing it this way. I'm trying not to step into any. potential problem and trying to make it so that everybody gets their say in a fair and equanimous way.
The WP Builds podcast is brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting that includes free domain, SSL, and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. You can find out more by heading to go.me forward slash WP Builds. And again, sincere, thanks to GoDaddy Pro for their support of the WP builds podcast.
Like I said at the top of the show, if you fancy making a comment, it would be really nice if you felt like heading over to the episode on WP Builds .com. Search in the top right hand corner for episode 3, 3 8, and leave us a comment there. We'd really appreciate that.
We'll be back on Monday for this week in WordPress, our live show. Join us 2:00 PM. UK time. WP Builds .com forward slash live. And we'll have another episode for you. It'll be David Waumsley and I having a chat next Thursday.
Until then I'm going to fade in some cheesy music. Wish that you stay safe. And say bye-bye for now.
