Fully Understanding WordPress Security Layers with Calvin Alkan

[00:00:00] Speaker A: Welcome to within WordPress, your podcast, your favorite podcast, I hope introducing people very active in the WordPress community, as well as those that we don't see very often. With us today is Kelvin. Welcome. [00:00:14] Speaker B: Kelvin, welcome. Thanks for having me. [00:00:17] Speaker A: Sure thing. Would you please introduce yourself and tell us what you do with WordPress? [00:00:22] Speaker B: Sure. My way into purpose was kind of like odd, I guess it's like that for a lot of people. So I was studying mechanical engineering, but I always liked the programming part more. So we had several classes during the years on programming like c sharp and whatnot, and I always kind of enjoyed that more. So naturally I was geared more towards that than my actual field of study. And then someday for a relative asked me to build like a website. When you study anything technical, assume to know, yeah, I didn't know what WordPress was, I just researched how can you build like an easy website. Found WordPress and got into that and I liked, so I kept doing like that during my studies and it naturally evolved in a way where I was doing more complex projects really quickly. And then I hit a point where I realized this is like all pretty much a house of cards if you take it too far. Where I then got into like I knew c sharp back then, but I didn't have this assessment yet that pretty much all WordPress products, or not all, but the vast majority of WordPress products, plugins especially, are really poor software from a quality perspective. I think you had an episode recently with till from Object Cash Pro where you talked about the software quality issue in WordPress. [00:01:54] Speaker A: One of the second episode, yeah. [00:01:59] Speaker B: So I came to that realization pretty quickly and from there on we did pretty much all projects that we did custom. So we built custom PHP applications kind in WordPress like systems that are really complex, like connecting a custom stripe API with booking systems, scheduling systems, gift card systems. So we developed web applications kind of based on WordPress, mostly like bespoke PHP development, and that's how we progressed through the years. So we never had a huge amount of clients. It was always few select projects, but they were on the higher end, like, I don't know, twenty k euros and up, whatever. And then I realized that security is not really an aspect that is handled that well in WordPress and we solved for that for our clients with custom solutions, but they were not reusable, extractable. And that over the years then turned into what we do now with Fortress. So like over the last two and a half, three years, maybe we spent time extracting all of our custom security work that we did into a reusable software that can actually be sold and used by anybody that's not having a bespoke custom built, if that makes sense. So it was all like a weird transition, not like planned in any way, which I feel is like for a lot of people. I think recently you had this, I enjoyed this Twitter post where you asked what's your way into WordPress? And a very diverse background said, yeah, I asked people. [00:03:44] Speaker A: I asked people on Twitter or X, we should probably say. I asked them. So you're working in WordPress now, but what did you study for? And the answers are, well, first of all, nobody studied for WordPress. Some did some computer degree stuff, but the vast majority has nothing to do with this line of work. And that was fun to see. Yours would be an example as well, mechanical engineering. I didn't study in this direction either. Well, maybe slightly, a little bit. I did business it, so kind of touches it, but not really. [00:04:21] Speaker B: Yeah. And yeah, that's how we got into security. We created Snico, our company, and we sell a product called Fortress, mostly to WordPress hosting companies, not to end users. And apart from that, we published a lot of really in depth research in the WordPress security space, which I've seen those. Yeah, I don't remember where it was, but you were on some podcast where you discussed the malware madness stuff that we published about the efficacy of the WordPress malware scanning ecosystem. [00:04:57] Speaker A: I think it was in WP builds. [00:04:59] Speaker B: It might have been WP builds. [00:05:00] Speaker A: Yeah. [00:05:01] Speaker B: So, yeah, that is what we do. [00:05:03] Speaker A: Okay, so you already mentioned a tweet that I sent out, but I think there was a tweet of mine that sort of triggered you and reaching out to me. So at one point I have tweeted something along the lines of saying there's a lot of stuff WordPress can do, but there's a few things WordPress shouldn't be doing. And one of the prime examples that I give is that security as most people know it. I should add that caveat, but I didn't add that in the tweet is something that shouldn't be handled inside WordPress, but should be handled before it even reaches WordPress. So at the edge, I know there is more to it. Correct. My biggest gripe was in this tweet, and I'll link it in the description, but was more geared towards everybody adding all these security, quote unquote, plugins that in reality are more obscurity than they're actually doing something. But you commented on that. [00:06:15] Speaker B: Yeah, me and I think also now, whatever. Yeah, I like the tweet and I messaged you and hey, I have so many thoughts on this. Let's do a show on that. I think because the tweet in its essence is accurate, but there was something missed. So you were talking about when you said security that I will never solve instead of WordPress, you were talking about, so you gave examples of banning ips or banning bots or spam. And I 100% agree you should never do that in a WordPress plugin. So that part of the tweet is 100% accurate. But it's more nuanced than that because there are some aspects of security that you cannot solve at the edge or at the CDN or cloudflare or whatever you're using, and you can't solve them at the server layer either. Some things you can only really solve inside the application. And yeah, if you're up to that, let's dive into what these are, because I think one of the biggest misconceptions in WordPress and the WordPress security ecosystem in general is not understanding that security must be layered. You can't solve everything in one solution and you can't solve everything at one layer. And if somebody tells you that they're. [00:07:35] Speaker A: Most probably lying to you, they are. The reason I tweeted, what I tweeted is essentially, I know there's more layers. There's a difference between what I think people should focus on versus what is actually what makes sense. I want to clarify for those listening and or watching what the edge means because it's something we'll discuss. We'll probably touch it a few more times during this podcast. But the edge is considered everything that is in front of your website. So Cloudflare is probably best known for being the most versatile edge solution provider, meaning anything that happens on a level of Cloudflare doesn't actually touch the server on which your WordPress installation is hosted. [00:08:27] Speaker B: On, I'd say before your server, not before the website. So before it reaches your server basically, or your hosting provider's server, that's the edge. [00:08:39] Speaker A: Yeah. So if you're hosted with any WordPress company, it essentially doesn't touch that part. It's whatever happens in front of it. But yeah, there are layers to security, many of them. In my defense, the tweet was meant to spark a discussion. Wonderful we're having. [00:09:03] Speaker B: That's good. Yeah. [00:09:05] Speaker A: But yeah, there are layers to security. Many of them. I think most people will know the most obvious one, and that's probably two factor authentication two fa. But there's a lot more. [00:09:19] Speaker B: I like to give this analogy from, actually, that is mind size. It's a pretty respected WordPress and books agency. They, in response to a malware madness research, created a post or a concept, which they call like the swiss cheese model of security. And I intuitively, they are correct in what they're saying, but they put it just into a brilliant analogy. So I always take that now and use that to explain it. Actually, if you want, we can show the image. I don't know if you can share your screen. We can definitely link it in the show notes, I guess, like the image of the cheese blocks are like a picture says more than. [00:10:06] Speaker A: I'll link it in the show notes. All right, so what's not to like about cheese anyway? [00:10:13] Speaker B: Imagine your security stack of blocks of swiss cheese stacked on top of each other. So swiss cheese, each block has a lot of holes in it. And each cheese block in that case represents one layer or one aspect of security. And one or two might not be enough to protect you against a vast amount of threats. But if you correctly assemble your blocks of cheese in a way that each holes are covered by blocks of cheese below or above that don't have holes at that specific point, then looking from top to bottom, your stack of cheese now doesn't have any holes or security gaps. Does that make sense? I feel like looking at the picture is like, that makes so much sense. Explaining it is rough. [00:11:03] Speaker A: You could say if you have, I don't know how many layers there are, but let's say there's eight layers, you would have a slice of cheese from eight different cheese. And then there's no chance that the holes in the slice number one is going to match exactly with slice number two, three, four, and so forth. Ultimately, stacking it means there's bound to be a blocker somewhere for the thing that is trying to get inside your site. [00:11:36] Speaker B: And the holes inside each block of cheese naturally represents what you cannot do at that specific layer in the security chain or security stack. So it's really brilliant analogy. We'll link it. My only issue with this, it's too complex for most people in WordPress. It's 100% accurate. I agree with everything that said there, but there are too many layers. I feel like it's too complex. So I like to break it down into the edge, the server layer, the application layer, which is WordPress, and then behavioral best practices, it's easier. So imagine like you have only like these four blocks of cheese, there's less cheese here. [00:12:20] Speaker A: I don't like that, but yeah, it makes sense. [00:12:23] Speaker B: And then let's maybe give a quick definition of what you would do at each layer. And then we can dive into what happens if you mismanage the different layers, if that makes sense, or mix responsibility where they don't belong. So at the edge layer, which would be your Cloudflare or other CDM products that are in front of your web server, in front of your hosting provider, maybe you integrated that and pointed the DNS there, or some hosting providers have cloudflare enterprise integrated or similar things at that layer. What you can do is blocking countries by IP, blocking user agents. You can have dealers protection, you can block spam, or for example, if you have a static IP or you're in a corporate office and everybody has like the same IP range, you can restrict access to your WordPress site by IP. Each of these things are best handled at the network layer because this is what you talked in your tweet about. You want to incur as little load as possible on your server. You don't want to consume resources. It's not that these things can't be handled at the plugin layer or the WordPress layer. Sure, you could have like a WordPress plugin or whatever that checks the IP, then fetches the geolocation from that IP and then denies your request. But then you basically already incurred 95% of the entire load across the entire stack. [00:13:53] Speaker A: That's a plug in doing a lot of things. [00:13:55] Speaker B: Anything there? [00:13:56] Speaker A: Yeah, that's a plug in doing a lot of things it shouldn't be doing. It's not a smart solution and you're. [00:14:02] Speaker B: 100% accurate in your tweet. And I feel like you talked about this layer. The other important thing is like a generic web application firewall should live at the edge and it's important to say generic. I feel like you had another recent discussion or tweet where you had like, there's like Cloudflare Waf web application firewall looking down on plugins. Yeah, something like that. In my opinion, you can run a generic firewall in the generic firewall. How I define it is you could take the same firewall, put it in front of WordPress, or put it in front of laravel, or put it in front of a symphony project, or put it in front of a node JS project. It doesn't make a difference. It's generic in that sense. It's not tailored to your application. So there you can block like analyze all query request parameters, look for xss, look for SQL injection attacks. And these are all pretty generic where you just basically only need knowledge about the request parameters that come into your stack and then get passed down to the server and to WordPress. All of this. This is a generic web application firewall should happen at the edge because it's way faster and you don't incur the resource head basically, of doing all that in the server, which is why I think I responded, it should be like your Cloudflare web application firewall looking down on plugin based reg x checks, because that is pretty much what every plugin does. They analyze all the request parameters, the get post cookies files that are uploaded and then perform extensive regex checks on them, which is like not the most, the fastest thing to do in PHP. And even then you already occurred so much cost. Your web server was hit, you booted WordPress. It's not the best place to. It's not that it's insecure by design, which there are some things that are insecure by design. If you do that the wrong layer, it's just not resource efficient and you waste a lot of solar resources, you consume more energy than you need to. And also, which is another important thing, you can't benefit from the, let's say edge intelligence, where all these providers aggregate a lot of data, they become better and better over time, which in a sense, some plugins also have that, but not to that scale, if that makes sense. They're not cloudflare. They don't have that much data. I don't want to say cloudflare. There are other products, but I feel like when people talk about the edge, it's pretty much synonymous with, yeah, I use Cloudflare. [00:16:37] Speaker A: I think they're the ones that coined the term as well. So kind of makes sense. [00:16:41] Speaker B: Yeah, they do a pretty good job of coining these security terms. Also, like now, the zero trust stuff, they do a pretty amazing job of that. So this would be the edge layer. [00:16:56] Speaker A: So one question, the edge layer as you describe, and let's take Cloudfra, for example, because it's the one most people can relate to. Inside the web application firewall, there are settings that target, specifically WordPress. There's a set of rules that you can activate as well. Are you saying those have less of an impact than what you would hope them to do? Because you're saying a waf is a generic thing and then there are. [00:17:28] Speaker B: But let's take this for, I said generic because the counterexample of them would be then like a web application or firewall that runs inside of WordPress where it has access to all the session information and the current context of the request, which Cloudflare doesn't have because it's on top of that. So you can't really assess is the user authenticated? What kind of privilege does he have? That's what I mean, like generic in a way that you could put it in front of a different application altogether. Sure, they might have some rules, for example, like I'm making stuff up, like be more strict about WP lock in PHP page, for example, and maybe apply stricter checks there, but they don't have access to the runtime or the current request. [00:18:17] Speaker A: From the WordPress perspective, that's a good distinction. [00:18:19] Speaker B: Also need sometimes that is my distinction between generic and then WordPress specific firewall, which would be like for example patch deck blocking a specific exploit, but only for example if you're not an administrator, because then you break. [00:18:38] Speaker A: Yeah, there's no way something on the outside of WordPress can actually do that. [00:18:43] Speaker B: You could, for example, let's say you have a vulnerability that can be exploited by sending the parameter x with the value of y, and then you have a zero day in a plugin. You could block that at the edge layer. The issue is how do you make it user friendly in a way that the legitimate users can still use that zero day? Does that make sense? Because you don't know if the person sending the request is actually an attacker, or if it's maybe the legitimate site or an editor. You could just shut that endpoint down completely. But then you also break functionality, and if you break functionality, then people will turn it off. That's like the reality of security. So at that point there are some firewall aspects where you need access to the current WordPress context. You need to be able to see, who is this administrator, is it an admin, is he not authenticated? And stuff like that which you can't easily transfer. For example, you couldn't put patchtag right now, the WordPress plugin into a laravel application, because that's entirely different. The context of laravel, the authentication system of laravel works very different than how it does in WordPress. But you could put cloudflare in front of both pretty much without any major issues. So that's the distinction I draw with generic and work specific firewalls. [00:20:07] Speaker A: Got you. Thanks for clarifying. Because I think that there's room for understanding which part involves what. And looking at that cloudfare firewall. There are rules within it that specifically target WordPress sites, but those are more in term of I'm on the generic level still, but I'm making it slightly more specific. [00:20:35] Speaker B: Correct. [00:20:35] Speaker A: It's still not specific with understanding the visitor. What is their role on the WordPress site? What are they doing? What are they allowed to do? All those sort of things. [00:20:52] Speaker B: Correct. So that's the edge to raise my window here because it looks like it's night, there was so much light and I turned it down. It's a bit better now. [00:21:03] Speaker A: Yeah, no worries. [00:21:04] Speaker B: I was so dark here. Okay. Yeah. So that is the edge layer pretty much, yeah. And below that is your server, which is the server security is almost always managed by your hosting company. And I think that's a good thing. It's not something you worry about. For example, hosting companies run stuff like cloud Linux or OS operating system security. Or they have their different separations of concerns between different sites on a server. Maybe if it's not shared hosting but they have their container strategies. For example they're using docker based setups or all these OS level stuff. [00:21:48] Speaker A: Yeah. There's various ways of securing your site on server level. I don't know how many different abstraction levels and layers there are, but there's a ton that you can do on server level just by creating small versions of containers. [00:22:07] Speaker B: Correct? Yeah. In my opinion malware scanning should live here. I don't want to summarize malware madness again, we can just link out to it. But in my opinion malware scanners, they should run at your server level because then the actual malware running inside your WordPress site can't affect or alter your scanner. And then the server level because you don't want the actual processing and scanning of files to happen on your server. You just basically want an agent in my opinion that scans everything and sends all that data remotely to a server controlled by the malware scanning company where they then do all the heavy analysis. Because if you do it on your site you will consume your server resources, which you don't want. But it's really important in my opinion that malware can't alter the scanner or in this case the agent or demon running on the server that is collecting the actual information, file changes, logs if it's able to be altered. And this is like what we talked about with. There are many malwares getting plugins that have like a local component as a WordPress plugin and then they send off the files remotely to be analyzed remotely on a remote server. The issue with that is yes, you don't have the resource hit anymore. For example with stuff like wordfence or local scanners, how I call them, they can be tempered and they consume a lot of server resources. And if you shift analysis off remotely, then you solve for the resource part. So you're not consuming the resource, but it's still insecure because malware, what it can do is it can actually temper or sit between the communication between your plugin and your remote application man in the middle, correct? Yeah, in a sense. So if I install malware, let's say in a must use plugin, and if I hit that endpoint, it just opens a reverse shell for me or whatever, and then your local scanner comes along and says hey, okay, look, this has been modified, I don't know this yet, and it wants to send it off. So the malware can basically, we publish stats on that, they can intercept that communication and just look at the API response that is expected by your remote application and just send it back like, hey, no changes here. All good? [00:24:31] Speaker A: Pretty much, yeah, it can issue, it's in the same layer and thus can act as if nothing is really going on. And while all the while you're fully vulnerable. [00:24:43] Speaker B: So that is why that information collection part, in my opinion, also has to happen at the server layer. It could be like just ideally some compiled binary that runs as a demon and watches stuff in real time. [00:24:57] Speaker A: So this is something, this is something that a hosting company should solve? [00:25:03] Speaker B: Oh yeah, definitely. This isn't something that any WordPress end user should ever get into. And we'll come to that topic I guess in a bit. But yeah, this is absolutely done by the hosting company. [00:25:17] Speaker A: Are you testing different hosting companies to see how well they're doing their thing? [00:25:24] Speaker B: Yeah, we do. [00:25:25] Speaker A: And have you published these results at all or is that something you give back to the hosting companies? [00:25:31] Speaker B: It is from a malware scanning perspective. We looked at what people have integrated. It was more like it's tricky because most of the malware scanning commercial malware scanning products that are not WordPress plugins, they basically have some clause in the terms of service that you can't basically perform analysis of their security or efficacy. And I didn't want to go through all that process of hey, can I have permission for this? And whatever. So we mostly focused on the plugin part, which is like, I can do anything I want on my system, but also tricky because some remote plugins. So some remote plugin scanners also have stuff in their terms of service that you can't test the efficacy of their remote part. So what you did there? [00:26:24] Speaker A: Yeah, of course. [00:26:24] Speaker B: Basically I didn't want to mess with any of the legal stuff. The malware madness stuff took us probably two months and I didn't want it to go like three months, make it three, four months. Yeah. So for the local stuff, what we did is we published the exact proof of concepts of malware that we wrote that completely renders them useless. And then we basically gave that to patch deck as an independent party to verify. And then they basically backed, look guys, we have verified this. Everything that's been outlined here theoretically is true. We have received a proof of concept of this because obviously we don't want to go ahead and raise the skill level of any average warpath hacker by giving them free malware templates to use, if that makes sense. That makes a lot of sense for the remote scanners. We did it conceptually and taught them and showed patch basically. Look here at this point, if you change this bit of code, send this response back, it will not be able to tell the difference. But I can't show you the results of testing it with actual remote service me locked in there because that terms of service prohibited us from doing that. [00:27:32] Speaker A: Right. [00:27:33] Speaker B: And that's also the case for the. I don't know, I haven't checked for OS stuff like there's monarchs, there's immunifi 360 which a lot of hosting companies use. [00:27:47] Speaker A: So in terms of what's happening on server level and attacks that are being deployed, is this a constant bombarding and ever changing? They're trying to get into the server level via different vectors. Because if I look at the exploits of plugins inside of WordPress, I know for a fact that as soon as a vulnerability is known, whether they have researched it themselves or they found somebody saying something about it. From that moment on you will get a lot of attacks on scanners that. [00:28:27] Speaker B: Go through websites for major plugins for sure. And if there's any zero day out, it will be exploited. [00:28:34] Speaker A: So how much is this happening on server level? [00:28:37] Speaker B: On server level I'd say the skill level is higher. Yeah, I would assume it's not the low hanging fruit. But just for example, check like for example on grip end which we use for our own site. If you look into the fail to bun logs there for SSH connections, you will see constant bombardment of people trying to get into your SSH connection with trying to brute force that. So it's also definitely happening at the server layer. I don't really recall any recent examples, but sometimes there are like zero days in Linux in OS level functionality. Like something that's shipped with Ubuntu, and not necessarily Ubuntu, but like some program that is shipped with it. Some zero data can be exploited. Basically, compromising a worker site through the server level is way harder than compromising through the WordPress site. I see it more like the server level layer assists in making sure that you can't get in through the WordPress site. That makes sense, not necessarily going through the server layer. I mean there have been some instances, for example, I don't want to get the dates wrong, but it must be like two years ago, maybe a little less, maybe a little more, where Goldie had like a big breach where their database was hacked and then the credentials or the WordPress information of the sites there were compromised, basically. So this also can happen. But it's rare that somebody gets hacked through the hosting company directly or through the server stack. [00:30:21] Speaker A: I only know of a couple of instances for as long as I've been doing this, which is I guess 18 plus years. It's rare, but when it happens it's horrendous. [00:30:33] Speaker B: Yeah, because then all the sites on the server are pretty much done if you get into the server level. [00:30:39] Speaker A: So server level is something a hosting company needs to take care of. Is there a way for us to check? Like how do I know if a hosting company is any good? Do we just guess or hope for the best? [00:30:54] Speaker B: It's really hard to tell if you're, let's say regular end user or WordPress pro agency. [00:31:01] Speaker A: Yeah, whatever. [00:31:02] Speaker B: You want to categorize that because you don't have the technical knowledge to assess the solutions they're employing. I mean in my opinion stuff should be handled. Malware scanner should be there a server side malware scanner, there should be definitely server side backups which we can also go into later, which I put like in this behavioral best practice layer, you don't want backups to happen through your WordPress site. And this will most likely be like our next research topic, like assessing the security of the WordPress backup ecosystem. Because imagine like the worst case scenario, you're hacked and then you only have plugin based backups and then an attacker deletes all your backups because he doesn't want you to be able to recover quickly or maybe even because it's just mean, then they delete all your backups. That is like the absolute worst case scenario. And I think that the way that's being done right now with plugins is really risky because most of them allow you to have back and forth communication. I mean if it's local backups, it's completely doomed anyway because you can just remove them from the file system. But if you have remote backups, really make sure for example that they are append only and can't be deleted from within the WordPress site. Because if that's possible then what's stopping an attacker from just deleting all your backups? Or they also have to be immutable. So what also can happen is they inject the malware that they have on your site and inject it into your backup, into the backup that can be tempered. So this should be also handed as a server layer. Felt. The bun is good for like SSH connections, os level security if it's available. Something like cloud Linux is good, but it's hard to assess for an average web, which is where this trust element. At some point there needs to be like a trust element. Hey, I trust this company. If I can't assess their security stack, there needs to be some element of trust somewhere in this chain. [00:33:15] Speaker A: Yeah, I think that's inescapable. Having worked at a hosting company I know a bit more about the ins and outs. There's a very long list of things being done there. Some of it you can tell and most of it you can't because that in itself is a vector. But it's hard. [00:33:42] Speaker B: Like disclosing what is being done. [00:33:44] Speaker A: Yeah. So from the moment you tell this is what we're using to protect you from that. That also means that if that solution ever gets a zero day exploit, you are very quick to understand where you need to be because. [00:33:59] Speaker B: Yeah, that's true. [00:34:00] Speaker A: So the disclosing of what software you're using in and of itself is a vector of attack. It's a rare one, but it's one that is most certainly there. Yeah. It becomes, I feel like in a. [00:34:14] Speaker B: Sense that is though probably not the same. But it reminds me a bit of this hiding which WordPress plugin you're using because people think that hey, if I'm vulnerable then people have like this, I'd leave with this. They have this notion of an attacker is going to check their site manually and then check which plugin they have. No, it's like they just bombard every single URL that they can find, like hoping that this exploit is active. Right? [00:34:43] Speaker A: Yeah, that's an entirely different concept within security where if you look at all the WordPress security plugins out there, the vast majority does some level of obfuscation which is hiding your login. Sure that helps some of the scripts, but anyone worth their salt is not checking for if wplogin PHP is available, they'll have different ways. [00:35:12] Speaker B: Just hit it. [00:35:13] Speaker A: Yeah, they just hit it. And if it's not there, fine, we'll find a different way. But moving it to a different location, it eases your soul I guess, but it doesn't really do that much for anyone being really serious. [00:35:24] Speaker B: And we definitely have to get into it a bit because a lot of the WordPress security ecosystem right now is basically not making you secure, but making you feel secure. [00:35:36] Speaker A: Yes. [00:35:36] Speaker B: Which is what most people want anyways. They want to feel secure. So that long list, they want to feel that hey, everybody, or not everybody, but most like WordPress agencies or let's say WordPress power users or whatever, they know they're supposed to do something and they just want to know, hey, I'm doing, and have that self, how you say, self assurance that they're doing something so they can feel secure. Whether they are secure is a different question. [00:36:05] Speaker A: I think there's quite a few security plugins out there that just have that long list of attempts, right. So every single bot trying to get in, just scanning wherever they can scan on your site, but then list that in terms of, look, this is all the stuff that we blocked and an attempt to check your login is not necessarily an attack, nor is it very important. But the long list of look at what all the stuff that we blocked gives you the idea. [00:36:37] Speaker B: This is so disingenuous because they send you like an email, like urgent so and so to me, failed lock in on your page which makes people think like, hey, this plugin must be working really hard. [00:36:52] Speaker A: Exactly. To me this is marketing. The marketing within security. I find. Let's start with a word, let's call it simple. It's a very simple way of hijacking your feelings of how well something is working. And you do that by marketing and it doesn't bear any real, I'm not. [00:37:19] Speaker B: Saying that to alarm fatigue, which is a very big problem. Yeah, people just stick their head in the sand and then if you actually need to reach them, how are they going to take action if you have been bombarding them with 500 messages a day? But that is like an entirely different topic which I could go on and on about. [00:37:42] Speaker A: Yeah, same here, same here. [00:37:46] Speaker B: Let's just say it's disingenuous. [00:37:49] Speaker A: Yes. I think it's a version of marketing I don't feel comfortable with in terms of confirming if this is working or not. I'm not saying it's not doing anything I'm just saying that that particular portion is not what you think it is or it doesn't do what you hope it does. And that's a shame because just think. [00:38:12] Speaker B: Of it like Cloudflare doesn't send you an email when each time they broke a bot. [00:38:16] Speaker A: Exactly. And they do it 24/7 nonstop. Yeah, you would freak out if you learned all the things they do. So we're already sort of moved on to the next layer. [00:38:32] Speaker B: Right, right. We covered edge. We covered the server layer. Now the application layer, an application layer in this case is the WordPress layer. WordPress is your application. [00:38:43] Speaker A: So what should people be doing? [00:38:46] Speaker B: So I want to cover the two myths that are also prevalent here, which is just use good hosting. I've seen this quote so many times like various Facebook groups when people ask like, hey, I'm thinking about using so and so or so and so plugin or what are you guys doing? And it's just use good hosting. [00:39:07] Speaker A: Or I just, as a solution for. [00:39:10] Speaker B: A, like just use good hosting and then you're done. Or just use Cloudflare and you're done, which is like, yes, you need them. They are at different levels, but they can't protect you against threads at the application level, which are plenty. So just to give a couple of examples, WordPress uses MD five password hashing by default, which is like outdated, like probably 20 years and it will probably never get updated. There's like a track ticket that is open like since nine years or whatever to basically update that. And there are some solutions that replace that basically with secure password hashing. So when your site will inevitably have a vulnerability, an SQL injection vulnerability where somebody can dump your entire database, they can't crack all your hashes in a matter of minutes, basically stuff like that. You can't do that at the server layer. You can't do that at Cloudflare. Like Cloudflare can't change the password hashing implementation of your Weber site. That will be one example. You can't do anything with two fa or authentication related at your server layer. It's impossible conceptually because you need access to the WordPress runtime, you need access to call WordPress functions. You need access to set WordPress specific cookies. It's not possible to like generally you always want to push security as high up in the stack as you can. So you want to offload as much as possible to elements higher in the chain. You don't want to block ips in your plugin, push it off to Cloudflare or you don't want to block an entire country in your plugin, push it off to Cloudflare or your server if you don't have Cloudflare, whatever. But sometimes it's conceptually not possible to do that because by design it doesn't work. Stuff like virtual patching where you need, we already covered this a bit, but like virtual patching where you want to make it secure and user friendly because you need access to the WordPress runtime, doesn't work at the server level, doesn't work at Cloudflare. Stuff like session security, which is absolutely non existent in WordPress. If you log in, basically you stay locked in for a very long time. And we'll probably publishing research maybe in one or two weeks with, we watch your websites, which we did, like the Molly Matt and stuff. They have a ton of data on hack WordPress sites. I think they're monitoring like 6 million sites right now. A shocking amount of WordPress sites are hacked because the end user has malware on his local device. [00:41:57] Speaker A: Oh, I've seen that happen so many times. [00:42:00] Speaker B: And when he logs in, they just steal his cookies. Yeah, they don't steal passwords and usernames anymore. They steal cookies and sell it in marketplaces. And then you can just take that cookie and basically put it in your browser or you send it from the command line and then you're basically that user. You bypass all authentication, you bypass passwords. [00:42:20] Speaker A: I think this is bypass two Fa. [00:42:22] Speaker B: And this is like not theoretical. This is very much happening, like, and we have the data, we watch to back that up. [00:42:30] Speaker A: This is one I'd like to highlight because most people are not aware of this part. So they're just absolutely, I'm just updating my WordPress. It's up to date. My plugins are up to date. I got a great hosting, I got Cloudflare, I got the whole stack right. I got everything going right. And then I've seen this on a client of mine who got hacked really bad. And all the scans that were done made it pretty clear that there was no visible vector on the server on the application. So you then go, okay, so then there are other routes. And as it turns out, they got hacked two weeks later again. And that was the definitive, okay, now we know where it's coming from, because we had employed extra stuff and it was very straightforward. None of those things were touched, nothing was clear. But when we asked the client, like, what is the system you're using to log in? In, they were running some old Windows version, like not up to date, not even remotely up to date. And I think they had a combination of stuff in the browser, like extensions, and that was the way. Oh yeah, browser extensions continuously could get in and they were indeed stealing cookies. [00:43:53] Speaker B: There are a lot of, I think that. Who covered that? Cassie Zen might have been. She covered like recently. We can link it in the show notes about exploited browser extensions. [00:44:04] Speaker A: Basically, if you're not aware that that's a thing. I got everything covered. No, you don't. For instance, I have three kids and combined with all their devices, my devices, my wife's devices, everything, it's quite a bit of stuff that I have in the house that is running a version of software. I've taught my kids to understand the importance of having everything updated ASAP. So if I look around at my friends and they are running with outdated apps, outdated OS versions, outdated stuff everywhere, and they're fully not aware that there are plentiful ways of having an unsecure device. Clicking on a non, it looks very trivial in terms of it's a normal URL. I'm in a browser, I'm on a website. How can something go wrong here? But there are websites that are hacked which then have sites that have links that are attacking you and unsecured devices and it trickles down to, it happens. [00:45:16] Speaker B: Way more than people think. [00:45:17] Speaker A: Way more. Way more. [00:45:19] Speaker B: And the best way to protect against that is secure a local device. I mean, for example, if you're an agency and you have five employees, but I feel like it's not advanced, but it's too advanced for the majority of the worker space. Don't have them work from their personal laptop, like have them properly set up device where they can't install stuff, they can't remove stuff, they have to have more with skins. But this is like, I don't want to say too advanced because it's like in the infosec space, it's not advanced, but the majority of the WordPress code you need to tailor to your audience, basically, it's too advanced for the majority. [00:45:57] Speaker A: Yeah, but it's most certainly a vector that not enough people think about enough. So as a general note, don't just update everything on your WordPress. Make sure that the devices that you're working on are also up to date and be very reluctant into installing. [00:46:17] Speaker B: Don't use some weird browser extension for exactly stuff that you probably could live without from a developer. You don't know. You don't know what's their supply chain? You don't know. Does he have his GitHub account secured exactly. Does he have two fanos GitHub account? You don't know. It's a security risk. [00:46:34] Speaker A: This is a good way of understanding that assumptions is the mother of all fuck ups. If you assume you're going to be okay just because you're taking care of stuff the way you can see it, then you are most certainly having vectors that people will exploit. [00:46:51] Speaker B: Yeah, and the best way to protect against the session specific stuff is just having your local device secured. But it's probably hard to enforce. If you have a woocommerce site with, I don't know, like one K customers, you can't enforce that. All of them must have their local device secured. So you need session security at the application layer, for example to check. And this is like absolutely non existent. But think about like for example, if you have, I don't know, are you using GitHub or even easier, your banking site? Yeah, you don't build banking sites in WordPress, but I give it as an example because the concept is pretty clear. If you log in there and you go away for 15 minutes, you're not locked in anymore in the banking site, you shouldn't be. You don't want somebody coming along and then making a deposit or a wire transfer just because you left your computer. So you're not locked in anymore. This also ties into the session, the cookie stealing stuff. If I steal your cookies, it's probably not likely that you just locked in that right point and how most of these info stealers work, they self install, they dump all your cookies, send them off to remote location and then remove itself to evade like detection by your antivirus. There are some that are persistent, but the majority are like this. And then the cookies are sold in the dark web and marketplaces and whatever. And if your cookie is valid for like two weeks or whatever, like it's in WordPress, then that cookie can be used for two weeks. And if for example you have detection that hey, you left your site for 30 minutes, then probably either that cookie shouldn't be valid or at least you shouldn't be like a full administrator anymore. So if you go for example on GitHub it's done like this. You are always locked in, which I don't like that much to be honest. But I've never realized that I'm locked out on GitHub. But what they do is for example if you go then to your repository settings, yeah you can go to change your API keys or ssh keys, they always ask you for reauthentication so they demoted your privileges basically because you left your device or because your login was like a long time ago. And all of this stuff is pretty much non existent in WordPress. And you can't solve for that either. On the server layer it's conceptually not possible and there are many more things like this. For example, you can't have. One of the biggest issues in WordPress still unfortunately is SQL injection. Like going to any database patch deck. Wordfence doesn't matter. Type in SQL injection and you can see them pop up every single day probably or every other day in some plugin. So it's not a matter of if, it's a matter of when you run plugin on your site that has an SQL injection. So plugins should account for that, WordPress should account for that. You're not developing isolation and for example you can't recently released announced like vaults and pillars which is basically we manage to secure sensitive data from other plugins in your database and encrypt them without requiring code changes in the plugins. It just keeps working. But magically the data is encrypted, addressed in a database and then decrypted before it's passed to WordPress. We can link it in shown it's pretty complex how that works. But you couldn't do that at the server level. [00:50:15] Speaker A: No. How is that going to work? [00:50:16] Speaker B: Like if somebody makes database query, how you can't decrypt some things you just can't handle at the server layer. And if you try to push stuff into the wrong layer, for example if you push malware scanning out of the server level into the plugin level, you're insecure. If you push stuff down from the server level, for example to the site level. In the example of malware scanners it's just not that secure anymore. Best case it's just resource waste. For example with the pushing the IP blocking or geo blocking down into the plugin application layer, it's resource waste. It will work. It's not necessarily insecure either. If it's implemented it's just a massive resource waste. But some things you can't push down and some things you can't push up. It's just a matter of doing things at the correct layer, which is where I feel like we can get into the problems. A bit of the WordPress security ecosystem, one of them is like plugins are this all in one tool. Basically every single plugin mixes responsibilities from every layer. So they all do pretty much stuff that belongs into the edge layer, stuff that belongs into the server layer, stuff that belongs into the application layer and it just gives you a false sense of your actual security. [00:51:48] Speaker A: It does. So if you look at all these solutions we have currently available within WordPress. Right, security plugins, what would be your top three? That you will. Okay, if you're going to use it, this is the one you should be using. But turn off this and that. Or do you have anything like that. [00:52:10] Speaker B: For general security solutions or the plugin layer? [00:52:13] Speaker A: Yeah. Within your WordPress site. [00:52:17] Speaker B: Within WordPress site. I mean, I'm kind of biased. We develop like an application security product that we sell to hosting companies, but it runs inside Fortress. Runs inside WordPress if you don't have access to mean it's kind of hard for me to give a recommendation because I've peek behind the curtain. [00:52:41] Speaker A: Yeah. Which is why I'm asking you, because that's the interesting answer. [00:52:47] Speaker B: We reported vulnerabilities at the end of 2022 in over 25 security plugins with a total of 16 million sites affected. And they all eventually fixed it. That took sometimes months, sometimes I didn't disclose it. [00:53:08] Speaker A: Crazy. [00:53:08] Speaker B: Sometimes I didn't fix it at all. And all of these things were like, it's not like super complicated vulnerability chain zero day. It's just like basic practices like don't store sensitive data and plain text in a database. [00:53:25] Speaker A: So I'm asking you a very difficult. [00:53:26] Speaker B: Question then it is, because I think behind the curtain probably more than most people in this ecosystem, but I'd say like some vendors that have fixed their stuff reasonably fast, Isin's has been reasonably fast in fixing their mean. They also do a lot of stuff that shouldn't be done at the plugin layer, but they have some good stuff there. [00:53:54] Speaker A: So what's the best advice you can give then? Because obviously solving it everything perfectly. If you're saying, and I understand if you would be saying this, the best way to solve this is use our product. I get that, but that's not a possibility for everybody. [00:54:14] Speaker B: Yeah, sure. [00:54:17] Speaker A: There's a large component of solving your security is what we briefly touched on is the behavior around security. Right. So updating all the devices that you work on, using a password manager, using least privileges, huge. [00:54:35] Speaker B: Like don't make your clients an administrator. Start from like a bit and don't use a plugin for that either. Like you can do that in WPCLI and it's super easy. Create a role, call it client, and then you add capabilities and you don't start an administrator and then remove menu items or capabilities with some plugin it's the wrong way. You started no privileges and then you give privileges as you go. And if your client says you hey, I don't have access to this or that, and then you give it to him. [00:55:06] Speaker A: Basically, yeah, I 100% agree. The vast majority of clients just don't need all that access for most of them. It's also confusing having all these options and features. But if you look at what do I add to WordPress in terms of a solution that helps me be as secure as I can be. Is there any recommendation you can have? [00:55:37] Speaker B: I'm judging it by how good have they been in their interaction with us? Because we've interacted with every single vendor in the space, every single one, and every single one in some way or shape now runs. It was mostly in the two of a space. So we didn't do like an audit of every single security plugin. We focused on the two of a functionalities and every single one of them in some way or shape runs our code or our protocols now anyway because we gave it to them. But I'm judging from how they responded, I guess there is like this free plugin. I don't know if it's maintained by WordPress, but it's in the WordPress GitHub. So from the plugin contributors or whatever, they have like a free two fa plugin. It still has some issues. For example, it still stores your secret keys in plain text because, I don't know, we reported that like nine months ago with them. It's not getting fixed, but that one is okay. And they've been at least responsive. That one. I'd say if you want like a free or affordable solution or you don't have access to anything else, use that. Besides, I mentioned I like some of the things that iseams. Does that do like application layer security in some senses, items security, yeah, correct. Just don't fall for this all in one approach of like, hey, you have this one plugin and then you're secure and don't ever worry about it. And don't fall for the marketing basically. But it's difficult because a lot of end users in WordPress are not like 99% of users in WordPress are not able to make assessments about security. They just aren't. There needs to be an element of trust. [00:57:21] Speaker A: There has to be. I think that is inescapable because we can solve a lot of stuff in terms of, hey look, this is marketing talking to you, so be a little bit more judging in terms of the information that you see written but if we're talking security, it very quickly becomes you having to understand security. [00:57:46] Speaker B: Yeah, at the basic level you should probably, if you're an agency, you have a lot of clients, certainly basic level, understand some stuff. [00:57:55] Speaker A: But there's way more people than just agencies using WordPress. [00:57:59] Speaker B: And it is undoable if we're talking like end users, like non technical, just logs in, creates like a website and whatever. It's my strong opinion that it will be impossible to educate them on security. Absolutely impossible in my opinion. [00:58:15] Speaker A: Yeah. [00:58:17] Speaker B: For them, security is like, it's something that bothers them, has to be done. It's like compliance in some sense, which is why I feel that this needs to be handled from the hosting companies, which is why we built our product the way it is. We want to sell to hosting companies for them to just bake it into their stack and tell their customers, look, this is basically what customers want anyway. They just want to know, hey, we're doing something, you're good because there's really no other way to reach these people. You can't educate them, you can't explain it to them. They are not any way or shape qualified to configure a security product. It's just a completely wrong approach in my opinion. And for some reason, if you think about it, the hosting industry in its entirety has arbitrarily stopped standardizing their security stack at the application layer. So we've gone through the layers. So the hosting companies have some have edge integrations, cloudflare or whatever. Pretty much everybody does something at the server layer. But for some reason, and I don't know how that came along, it's not like that was some big master plan or whatever, but for some reason everybody stopped standardizing their stacked application layer as if crossing like the WordPress barrier is like some sacred line that you're not allowed to cross. Yeah, my question is why is that you don't let your customers choose their file system security or how they want to separate their sites, like what kind of folder permissions. You don't offload that burden to your customers. So why as a hosting company would you offload at a different layer to their customer? Just because it's in WordPress doesn't mean they're any more qualified to configure like application layer security compared to configuring their best Nginx configs. Does that make sense? I don't know how that developed, but this is like the main problem that I see in the space right now, which is kind of contributed to why we do things the way we do. But I don't know how to solve that. Like end users will never be able to assess what they need. [01:00:28] Speaker A: The problem you're aiming to solve is one that is, it even transcends WordPress in the biggest way. Like password managers, there is no sensible argument why you would not be using a password manager, why you want to understand or remember your passwords. Just getting people to understand that principle is just mind boggling the actual end. [01:01:01] Speaker B: Users in some way. Yes, you have agencies, you could probably educate them also. Like this is kind of what we're doing with our research, but even that is challenging. It is just don't want to know. And if you go like a level down, for example, it's just say like a generic shared hosting company. They don't have anything in their marketing. Some have stuff like free SSL, which I think is kind of funny. It's not like 2010 anymore, like free SSL. So what that should be like a given. I mean, but that's pretty much it. Because their end users don't care about security, but they all, in some way then go and install some plugin and think, hey, I'm secure. They probably misconfigure it. They misconfigure it tailored to their server stack. So then also they generate like support burden where your plugin level firewall conflicts with your server level firewall conflicts with something that you do at the edge. I don't know, it's weird. They're coming a lot of trickle down problems from offloading the application security to your end users. You don't do that at other layers. So why are you doing that at the application layers? I don't know how that developed basically to be the standard. [01:02:17] Speaker A: Yeah, no, I agree it's a weird thing that's happening, but it is most certainly the thing that we have to deal with because that is the world we live in. I generally like to end my podcast on a positive note, but this is a tough one. I don't know what to say or what to ask you to end up with a positive note. What would be your final closing and possibly positive note here? [01:02:50] Speaker B: I think ultimately we will get there. There are just too many benefits to doing it that way of having that all handled for the majority of the end users because it's also way more user friendly. Like no end user wants to log into their site and then sift through five nested tabs of security settings and configure something. They don't want to deal with it. They don't want to know about it. They just want to know and have trust that something's being done for the most part. So I think ultimately we'll get there. It will take a while. You can't do changes that developed over 15 years in a year will take time, sure, but ultimately I'll think there are a lot of good things happening right now in WordPress security on several different layers. I like what for example, Patchtech is doing. We talked to them about they all basically open a separate kind of database for reporting security neglects or something that can't be classified traditionally to a CVE system. For example, if somebody stores data as plain text that they shouldn't be stored as plain text. You can't assign CVE easily to that because you can't exploit it if there's no preconditioned vulnerability. But that doesn't mean that you should use that software and the vendor should absolutely fix that. But right now, and this has been our issue, there's no good way to report it in a way that end users will actually know about it and stuff is changing. I'm not negative about it. [01:04:30] Speaker A: No, you're being very realistic about it, but the conclusion has to be a negative one. [01:04:36] Speaker B: If there's so much right now. The security ecosystem morbid is not in the best space. But I feel like we'll absolutely get to a place where it's not that much of an issue anymore. Or not as rampant at least Warp is will probably as long as the biggest platform will always be like the one that's for sure also the most hacked, just from absolute numbers. But the percentage doesn't have to be that high. It doesn't have to be like, I mean, I feel like ultimately I don't know if you have that same feeling the last half a year or so, like all the vulnerabilities, exploits, the sites getting hacked have been massively gone up. [01:05:11] Speaker A: They have, yeah. [01:05:13] Speaker B: So I don't know. We're not in the best spot right now, but I think it will get better. I'd say like easy fixes you can do right now. If you're listening as a site owner or whatever, ensure that you have really good backups. That is, I mean baked in at the hosting layer. You should have server level backups, you should have multiple sources of backups. So at least if you get hacked. [01:05:37] Speaker A: There is a way back. [01:05:39] Speaker B: You have a good way back and not from a plugin like make sure you have something at the server level remotely append only immutable, can't be deleted. Also, you can have full server backups at, I don't know, vulture, Hetzner. They all allow you to have full server backups on top of the site. Backups. Just have multiple sources of backups. Use what we talked about. The least privileges. Don't give clients any. Outside developers, don't make them administrators. I mean, these are like the basics. These are all free pretty much. Backups. Hey, what do they cost? Not that much. These are all things you can do and just get some basic understanding of the different levels where you can be protected and don't follow. Basically the all in one install this and then you're super secure stuff you aren't. [01:06:39] Speaker A: Yeah. So that's as positive as we can get. Thank you so much for joining. [01:06:45] Speaker B: Sorry. [01:06:45] Speaker A: No, that's fine. [01:06:47] Speaker B: I'm positive about the future. [01:06:49] Speaker A: You are positive about the future. [01:06:50] Speaker B: That's a good I'm positive about the future, but there's no need to sugarcoat. [01:06:54] Speaker A: No, nor do I think you should. And I say it in jest. It's more like me being facetious. But I 100% agree with every single thing you've said in terms of what to pay attention to, what type of stuff to focus on, what to be wary of, and all that stuff. But the end conclusion has to be that we are currently not in a good state. The positive note is we will get there because stuff is moving in that direction. [01:07:27] Speaker B: Stuff is happening. [01:07:28] Speaker A: Yes. And as such, I want to thank you for being on the podcast and sharing your knowledge. [01:07:36] Speaker B: Thanks. [01:07:36] Speaker A: I'm quite sure a lot of people learned a lot of stuff about what goes into the full concept of securing your WordPress site. So yeah, thank you so much.