WordPress Security: From Basics to Enterprise-Level Protection

Kathy (00:00):
Welcome to do the Woo. This is a very important conversation for my heart at least, because security is something that’s incredibly important for anyone working online, whether you’re doing WooCommerce, whether you’re in the enterprise, whether it’s just your cat blog, security is important because hackers are targeting sites all the time. I’m really excited about this conversation because we’ve got two of my great friends here, Carl Alexander and Calvin Elkin, and you guys, security is important to you too. So let’s just get into it because we started talking in the pre-show and we really got into it. So I know this conversation is going to be exemplary. So let’s just get started. Security for WooCommerce for e-commerce is different than just security for a CAT blog, isn’t it? A little bit.

Calvin (00:53):
So what we just talked about before we hit recording, it is not enough to basically give up at the first hurdle or the first line of defense. If you’re protecting important websites, whether it be an enterprise side, whatever definition it may be, or whether it is commerce, learning management, community, whatever it may be, your security stack needs to be layered and you need to be able to protect and still withstand if some part of your stack has a vulnerability. And I feel like in the worker space, there’s this mindset of, well, I am going to install a traditional security plugin or whatever it may be, and if there’s some vulnerability in my stack, then well, that’s that. And we’re not having that as part of our threat model,

Kathy (01:47):
Right? So it does seem easy. I mean, in WordPress there is sort of this mindset of, well, there’s a plugin for that problem solved, and that happens whether or not it’s like I need to change the way the code is appearing in a certain widget or how my footer works, or even how my theme is going to work, just install some software and snap problem is solved. But security is so much more than that. You can’t just install a plugin and say, well, the plugin’s doing the work. There’s configuration with it. There’s your password. That is your decision. So what are some of the things that you’ve seen, Calvin, in terms of maybe plugins not being the end all, be all solution to all aspects of site security?

Calvin (02:37):
So I guess the best example they’ll give is what we published lately with the Malware Madness stuff. So basically for anybody that’s not familiar with it, we together with the guys over at We Watcher website, they basically are a malware scanning service that is integrated at the server layer. They monitor about 6 million websites or so currently. We published research with them about how plugin based malware scanning is fundamentally a flawed approach. That conceptually is impossible. It doesn’t work because there’s evidence and a lot of evidence that hackers after they infect the site, actively temper with the malware scanners, so the malware scanning plugins and alter them in a way that they will not be able to detect any malware on your site anymore. And basically we published that research and well wrote exemplary malware to prove that actually is pretty easy. Obviously we didn’t publish that.

(03:35):
We had that verified independently by PitchTech who basically were the independent third party in this whole research. This would be a really good example because I feel like in the word security space, there’s always been a huge emphasis on malware scanning instead of proactively securing a cyber prevention. And this is one example where for years or maybe even decades, I don’t know, people were the go-to approach was like, Hey, installing malware scanner plugin, the emphasis on plugin and it doesn’t work. I mean, it works. If you’re attacked by anybody that’s really, really on the low end of sophistication, then maybe your scanner will detect that. But anybody that has a bit of skill, any remotely skilled attacker will, and they’re doing that, they will disable your scanner and your scanner from that point on will not tell you the truth anymore. And it’s like, yeah, it might be fine. For some sites, like you said, like a simple block mom and pop shop, it might be fine to say, yeah, how likely is it going to happen on my side? But for anything valuable where the entire business relies on that, it’s probably not the best approach.

Carl (04:46):
And also, I mean the first WordPress talk that I did at a meetup was a security talk, and I said that one of the threat that I feel is never discussed but is way more important is I say one of your biggest vectors, at least for most people is a disgruntled former employee. Do you disable their accounts? You talk about a lot. I think there’s, security is hard. I know enough about security to not call myself a security expert. So it’s hard to have enough understanding of fundamentals, but I feel like people don’t really understand this idea of multiple tread models, this idea that, yeah, okay, you installed the plugin, then that covers something. But actually for most people, you’re actually way more likely to have a former employee do something even for big companies. I think for example, in French Canada where I am, there was this whole thing with a bank this, and it was an employee stealing customer records for years, and it’s a bank, it’s just like these, it’s just like those are, if it can happen at a big company, it’ll happen to you. If you fire somebody and don’t disable their account, why don’t they just come and delete your site, delete your backups, things like that, right?

Calvin (06:20):
Also, plugin support. I mean, in saying that people give, not like to say that plugin companies are not to be trusted, but basically if somebody has an issue, they give the support team of a plugin, full admin Xs on their site, which is like, I mean, that should never happen, in my opinion. They should have been on, you should create a staging site.

Carl (06:42):
I’m definitely guilty of that. I’m definitely guilty of asking for an admin account for support purposes,

Calvin (06:49):
Basically giving them a staging site, a sandbox site with all data scraped, all sampled. But this is what people do. So this is also the same thing with the employees that steal their records. Somebody just mentioned,

Kathy (07:03):
Yeah, I once cleaned a site that of a plugin that was available on Code Canyon, and the plugin actually had a back door, just basically had the password in the actual file. So somebody would have to type in the password, or maybe it was on the query string, but the password was in the file. So a hacker got in through some other way, saw this back door that the plugin author had put in there, saw the password, and was able to hack all of the sites. So yeah, security for or providing a secure access for a plugin author to be able to get in and provide support. Sometimes there’s a weird conflict and you only can see it when you’re logged in, but that’s a security concern because you’re letting someone into your site. Calvin, I want to get back to why the plugin is, why that whole model doesn’t really work. Because of how PHP works. There might be some non-technical people who might not understand exactly how that model doesn’t work, and they might not be able to find time to read your research. But can you just give an overview of why that doesn’t,

Calvin (08:21):
You’re referring to the malware scanning stuff? Yeah,

Kathy (08:24):
The malware scanning. Yeah. What happens, I mean, I’ve seen the malware that’s done this, that’s like, oh, well, you can find everybody else’s malware, but you’re not going to find mine. And that hacker can modify those files. Can you explain why they can, why they get a site has an intrusion from, let’s say a SQL vulnerability, that SQL injection that does not have anything to do with anything happening in PHP, but they can still then get access to PHP files and modify them.

Calvin (08:59):
So let’s start by at the point of through some means your site has been infected, so it doesn’t matter that infinite attack vectors, how that could have happened, but now your site has malware on it, and you also have a plugin that does malware scanning, maybe like using the WP chron periodically, or you can start it from the ui, whatever. But ultimately this scan, the malware scan runs in the same process, the PHP process and with the same privilege level as the malware. So the most simplest and the most blunt hit with the hammer approach, the malware could just simply disable or delete your security plugin from the file system. This will be like the easiest to understand the first time the malware runs, it just deletes your security plugin. That’s the easiest after there aren’t any scans, but obviously you as a site administrator would realize that at some point, yeah, maybe not immediately, but maybe you’ll realize eventually that your security plugin is gone.

(10:02):
So what they do is then because they can read the source code of the plugin, they can see how it works, and since they’re operating at the same privilege level, they’re both running inside of WordPress in the PHP process that powers WordPress, they can then alter the malware scanner in a way that maybe imagine this. They’re very complex operations going on to determine if a file is malware or not, and then the actual malware modifies that final result. It is displayed to you in the UI and just says, yeah, you’re all clean. Pretty much that’s how it works. They make the malware scanner lie to you. They make the malware scanner tell you there’s no malware, but there actually is. And the way to do that depends on malware based on the malware scanner that you have. And obviously we didn’t disclose what we did there. We don’t want to make it easier for folks, but it’s pretty easy, to be honest, like 10 lines of quote maybe to do that. It’s not hard. So yeah, that’s the fundamental issue. The system that is potentially infected wants to monitor itself, and that doesn’t work. It has to be from somewhere higher up or someplace that is more privileged at the server level.

Kathy (11:19):
Right now, if you have a plugin that’s actually operating, I mean, there’s are some plugins that have firewalls associated built into the plugin also, firewalls would be something that would be blocking malicious attacks like cross-site scripting attacks and whatnot. Are those at risk as well?

Calvin (11:36):
I mean, not from the motor scanning site because the firewall is only useful up until the point where you’re infected. So the firewall would be protection, not scanning. I mean, if you have hardware on your side, the firewall can be disabled in the very same manner. That’s also the, but at that point, you’re already infected. The firewall usually is there to prevent you from getting infected in the first place. There isn’t anything wrong in particular with plugin based firewalls. It’s more so that everything that you can do in a plugin with a firewall, you can do, for example, the Edge at CloudFlare or in the Nix firewall.

Carl (12:15):
Yeah, just it’s heavy from a CIS admin perspective, especially in enterprise, right? We’re talking enterprise. So larger WooCommerce stores, larger sites, they need more PHP workers. They want their code to be more efficient so that the response time is faster and all those things. If every request has to be processed as a firewall request, it’s a lot of processing time dedicated to that. It’s not. Trivial in itself is a one serious reason to just not use super heavy security plugins like that is if they just do a lot and they put a lot of weight on your WordPress installation, which is a problem again for enterprise because they’re trying to be more performant, they’re trying to handle more sales, more everything, and you’re basically, it’s like having an ankle weight. You’re kind of dragging. Every request has this huge ankle weight that you’re dragging, and that serves not no purpose, but as we’re discussing the malware scanning doesn’t work. It’s more like security theater, right?

Calvin (13:35):
The malware scanning and some other things. Fundamentally, it’s impossible to perform that at the plugin level. And there are other things that are the same, but for example, the firewall, it is absolutely possible to write a secure firewall in a WebPress plugin. There’s nothing that makes it conceptually impossible, unlike the malware example. You can do that, whether the existing ones are secure, it’s a different topic, but it is theoretically possible. The thing is, it will not be performed because as Carl mentioned, at that point where the plugin based firewall runs, you already incur the majority of the cost of that request. You already went through the edge layer. Engine X ran, WordPress was booted, and then your firewall is hit. So it’s not performant. It’s possible to do it securely,

Carl (14:25):
Or let’s go one step further to you’re trying to mitigate a DDoS. If your firewall’s, the actual PHP application, you ain’t mitigating anything, right? Your site’s blowing up either way. It’s all cool. You have a firewall, but you’re still getting hammered by hundreds of thousands of requests. Php, your server’s not going to be able to handle it, and it’s not really designed for that either. You can do it on the same machine. I’ve done work with people that nonprofits where they can’t use American companies for security reasons, and so they can’t use CloudFlare or things like that. So you have to do a lot of the protection yourself at the machine level, but it’s not, you want those requests to be blocked. You can even overwhelm a Linux machine if you’re not careful, even with a DDoS. So that’s why it’s not efficient either, right? Part of the goal of a firewall is to prevent those DDoS attacks, and you basically are not doing that with a PV based firewall.

Calvin (15:42):
One example of this that is like doesn’t make a lot of sense. As for example, many traditional security plugins give you the option to block requests by country. For example, you can configure, only allow requests from Germany if you’re in Germany or US or whatever, and yes, that works, but if you think about it, you hit the plugin and the plugin has to reach out to some IP database to get the, so there is a remote call involving a different location to accurately or more or less accurately determine the actual origin of that ip. And then you block it. At that point, you incur so much of the cost already from a performance perspective, if you compare it to just blocking it at the CloudFlare level or whatever C D N you’re using.

Kathy (16:33):
Okay, so malware scanning should happen at the server level away from with permissions at the server level rather than the PHP user, server-based user level and firewall should happen someplace else. Is there any case for using a security plugin? What can a security plugin do? Well, when you’re talking about at that application level,

Calvin (16:58):
There are many things. So in my opinion, this all is a fundamental misunderstanding in the WordPress industry of the different levels, or sorry, layers in the security stack. And if you mix and match them and put stuff that belongs in one layer into a different one, you either end up with performance degradation or it’s conceptually insecure. For example, I tend to think it as you have the edge, so you have the network layer, everything happens before it actually hits your server. Then you have the server level, like engine X, so you already on your server, and then you have the application layer, which in our case no spaces WordPress or WordPress is the application. And there’s application layer security. And then the last one would be behavioral best practices, having backups, malware scanning, having proper permissions, the principle of least privilege for user levels, and that is adjacent layer, if you will.

Carl (18:01):
This is a good one. We should talk briefly about for people that aren’t, again, when I talked, I did that little intro to security principle of lease privilege is a really useful thing to know and is really applicable to anyone. So principle of lease privilege is basically this idea that you should only give people the minimum level of access that they need to do their job. So if somebody is just writing articles and not publishing them, you should just have them with the contributor access or things like that. And this is something, even if you have a personal site, you can apply to yourself. So for example, if I take my own personal site, like carl alexander.ca, Carl alexander.ca actually has two users on it. There’s an admin account, which I’ve never almost logged into, which has the admin privileges. And there’s the main one that I write with, which is if you can search things and things like that, you can see the username and things like that. It’s much more visible to find. And it only has publishing rights. It can’t install plugins, it can’t do all this stuff. And this is really useful. When we were talking again with disgruntled employees, for example, if the disgruntled employee doesn’t have the accesses to delete plugins or delete your install because you didn’t really need to in the first place, then you’re at least more secure for that. So principle of least privilege is definitely a really handy thing to know about,

Calvin (19:45):
And it’s pretty easy also to, I guess at the enterprise level, people are doing that already. That is not, I mean that’s pretty known, but it’s pretty easy to just create your own custom role. You start from zero privileges. For example, let’s say you’re building sites for a client, create a new role called client, which has no privileges at all starting, and then basically you add on the need by need basis. If the client wants to edit, I don’t know, some settings page or he can edit his phone number, email or whatever, then give him permission to do that. But only that. And if he needs to do something else, maybe he wants to, I don’t know, publish blog posts, give him permission to publish blog posts, but not, for example, to edit the templates of your page builder if you’re using one. It’s not that complicated, and you don’t need plugins for that either.

Kathy (20:33):
You make a very good point there, Calvin, because I see a lot of times even with developers that are like, okay, here’s this role, but I don’t want them to be able to do this stuff. So they start taking away things

Calvin (20:47):
They take away from admin,

Kathy (20:49):
So they start taking away things that they don’t want. And there’s this thought process or just this paradigm of understanding that you start from security with nothing and then add to it.

Carl (21:00):
I’m definitely guilty of that actually.

Kathy (21:03):
So because, well, you’re a developer, and so you think about being able to do everything, and so you’re in that mindset and it takes someone like Calvin, a security expert to come along and say, let’s start here. Let’s start from zero and what,

Carl (21:16):
But also you’re kind of thinking, okay, how are they going to break my thing? And then I don’t want them to break my thing this specific way as opposed to thinking from a security first principle where you’re like, okay, I don’t actually care what they’re going to break. Let’s just not give them anything. And then see when they start screaming and then we give them some access,

Calvin (21:40):
You’re also making it less likely to break. So if they have no permissions, they can’t really break anything if all they can do is edit some text fields or whatever. But to circle back as you ask what can be done at the WordPress level or at application level, there are a lot of things, and there are actually a lot of things that can only be done at the application level. The easiest example would be anything authentication related. So anything related to two A passwords, lock-ins, password policies, all of these things can only be done at the application layer. At least I haven’t seen anybody coming up with a way to have two f a in cloud flare. It is not possible because you need to be tied into the WordPress authentication system. To do that, you need to be able to generate WordPress specific authentication cookies. So there are many things that you can only do in at the plugin level. The issue is that a lot of people, including the plugin ulcers, don’t know which one these aren’t. So they just mix and match everything into one package, which is not like, it just doesn’t work beyond a basic level.

Kathy (22:56):
Yeah, very, very good points. Let’s talk a little about that application level. Been a couple of, well, first of all, your research about two f a, the seed and all of the information that makes two F a work being stored in a way that’s accessible and not encrypted in the database. And then there was also a recent story about was it Stripe, a p i? Let’s first talk about the Stripe a p I instance. What happened there?

Calvin (23:30):
There’s a huge issue in not related to security, but to all plugins in WordPress, which is that they all store various sensitive data as plain text in your web database under the assumption that, hey, the database is this Fort Knox type of storage that we assume can never be breached, which is true on, I mean, WordPress core had several Ss P L injection vulnerabilities over its lifetime, wherever actually vulnerabilities in WordPress core, that could have led to the entire database being dumped basically. But plugin also have this mindset of, Hey, my plugin doesn’t have a vulnerability that allows somebody to read arbitrary data from the database, so I don’t have to consider that in my threat model. So they just stuff everything into the database as plain text without considering that their plugins are not running in a sandbox, that customers will put that on the side where they have 20 other, and it’s not like a matter of if, it’s a matter of when, there will be a point in time where a given plug-in or WordPress score or SI has a vulnerability that allows dumping the entire database and reading everything that’s in there.

(24:41):
I mean, just going to any database patch deck, word fans, whatever, there are new vulnerabilities like that popping up almost every other day. It’s super common in WordPress. And so yeah, they throw everything as plain text into the database and was, I don’t remember how the plugin, I think the plugin was called Access, I don’t remember. It’s like an LMS plugin I think, which an agency was using. And then the site got hacked. It’s not entirely clear how, but the techers stole their Stripe keys. So the LMS plugin was using Stripe to provide payments, and they stored the stripe a p i key as plain text in the database, which if you hack a site can extract, or if you have an SQL injection vulnerability, you can extract that Stripe a p i key, and then they committed very, very significant financial fraud with that key.

(25:37):
So I think, so Stripe and Stripe made the agency liable for that or tried to make the agency liable for that, and I think it was like 70, 70 K that was committed or fraudulent transactions with their A P I key that they were liable for. And there are many other, every plugin basically does that, and it is a risk, but they don’t consider that. It ties into what I mentioned at the beginning is yes, this is not exploitable if you don’t have an SQL injection vulnerability, but as soon as that one brick, that one domino faults, you’re completely unprotected. So giving up at the first line of defense basically.

Kathy (26:22):
Right. So are there things that, let’s say we have some enterprise person who’s using any one of these plugins that is storing Stripe, a p i keys in the database plain text. What can they do to protect themselves? Is there any way that they can encrypt it? Do they just have to never sleep and watch their site incessantly? What can they do?

Calvin (26:46):
The best way is to keep bugging the plugin ORs into adding encryption of their sensitive data. Some do, some actually after it happened did, but many major plugins still don’t do that. Even after it happened. It was like a huge story in WordPress. Basically everybody was talking about this, what happened there. It was very widespread and a lot of users, end users were very concerned and the mind changed from their plugin vendors, but it didn’t really materialize, at least not widespread. So yeah, the best way is to obviously get your plugin also to fix that or consider alternatives because maybe that plugin vendor doesn’t have that threat model that your site requires.

Kathy (27:39):
So also minimizing the number of plugins that you’re using, only use plugins if you absolutely positively have to, the more plugins you add to a site, the wider the attack surface becomes because there’s just so many different coating standards with over 60,000 plugins and the repo alone. But Fortress is a product that you’ve developed that has, there’s some feature, if you can tell us a little bit about that, that you were offering for free that does protect from things like this.

Calvin (28:15):
So basically there is a way to tie into this mechanism of how WordPress retrieves data from the database. Right now it’s limited to the WordPress options table because that is where sensitive data is most commonly stored. Just to give an example, Stripe, a p i keys or keys to connect with Zapier or keys for RE or CloudFlare, whatever that may be. It’s all stored in the WordPress options table as plain text right now. And WordPress core is deep down in core. There are some low level hooks that you can hook into, and we leverage that to basically add a little encryption layer between the database and WordPress. So everything that WordPress stores goes through, translation layer is encrypted and stored encrypted and in the other direction, everything at WordPress retrieves is decrypted and then passed to workers. So you have encryption address of all the data, but everything still continues to work just as expected without, and the support thing without requiring any code changes in third party plugins. So you don’t have to wait for the plugin authors to be responsive or to fix their stuff basically. Maybe we can link the post or we described all the technical details of how that works. That would probably be too long to explain right now.

Kathy (29:43):
Sure. So there are solutions, but this kind of feels a little bit like you’re offering it for free. It feels a little bit like a stopgap solution right now while we wait for plugin vendors to kind of up their game in terms of encryption and whatnot. Right. Okay. All right. So that’s available. I think this is really important because like we were saying at the beginning in the commerce space, in the enterprise space security is, it’s not an afterthought. It is not something where it’s like, oh, well it got hacked. Let’s just restore from backup. Unless it’s just a brochure site and it’s isolated from everything else and it gets whatever, there’s no customer information on that. We don’t have to do breach notifications. There’s no G D P R concerns, brochure sites, whatever. But if you are in the enterprise, you do have customer information in a database, you do have commerce happening on your site, there are so many legal ramifications to having a security event.

(30:46):
So something like this might seem like pretty edge case, maybe it’s never going to happen, but when you have targeted hackers, like what we’ve seen with what has happened with M G M and all of their systems having to be shut down, the sophisticated social engineering attacks that are leveraging AI voice replication in order to do stuff like we are seeing more and more sophistication in terms of the attacks that are targeting enterprise that are targeting commerce. So talk to me a little bit about just all of the different hurdles that we have to consider. We can’t just say, oh, well, that’ll never happen.

Calvin (31:33):
Can you clarify what are you referring to with hurdles?

Carl (31:36):
All the things, all the things, Calvin, all the things. All the things, Calvin, it’s all the things. I mean, M G M is a good example when we talk multi trek model because for those who haven’t read on it is basically it’s just this hacker group that’s very well known for social engineering. They basically called managed to get a customer support because again, different, again, we’re talking enterprise here, you’re a much more juicy target for them. They’re willing, these groups are willing to spend some time to just develop what they’re going to, they’re not just throwing bots at you and just hoping something works. They’re like, no, okay, we’re going to do this properly. So they figure out, okay, well what are weak points in your organization as a whole, a whole, right? And customer service, for example, is a really easy one because for things that we’ve discussed already, you could have Trek models where you pretend to be a plugin author saying, I could arrive to you. I pretend to be like this plugin you’re using. Oh, we need to give you to give us admin access. We need to fix something. And then you don’t know better, and then you just give it to them. But for here, they use customer service. So customer service,

(33:06):
You’re incentivized to just close tickets as fast as possible without doing due diligence. So they just basically arrive and they manage to successfully fake that they were a high level access person that they needed their password changed for their account and they changed it, and then they were off to the races from there. So that’s one example. That’s why it’s all the things in enterprise, it’s all the things,

Calvin (33:34):
And that will always be entry points, which is why it’s crucial to not have this mindset of, well, if they’re already dead far, then it doesn’t matter. A lot of people in WordPress have, for example, this mindset of, oh, well this vulnerability isn’t important because it requires you to be a WordPress administrator. And it’s like, sure. I mean, it’s like a very simple viewpoint. A WordPress administrator should, for example, never be able to change the running code of the website, which is where we get into immutability and having an immutability deployment system, immutable file system, if I compromised the admin account of somebody, I should not be able to elevate that compromise into compromising the entire server by uploading malware. That should not be possible, and it’s like this mindset of, well, my admin account is already compromised and it doesn’t really matter because they can do everything already. Yes, if you approach it that way, but they shouldn’t be able to, and it’s not that hard to prevent them. Basically, it’s just a change in mindset,

Carl (34:43):
And I’m sure you’re used to discussing that too. Katie, Kathy was like, I’m so bad with the ths, but that’s why it’s insecurity. You talk a lot about risk management. It’s not about, oh, this is flawless. No, everything has a flaw eventually and things bad things are going to happen. It’s how you manage that risk of these bad events happening as well. Right?

Kathy (35:17):
Yeah. I always advise everyone to have an incident response plan because just going through the exercise of an incident response plan, you uncover all of the little things that you might not think are a big deal can be chained into a massive event. The target attack that happened in 2013, an HVAC vendor with an unpatched computer with malware on it hooked up to the target network and through that one entry point, it took 10 days, very patient hackers testing all of the internal vulnerabilities, all of the admin plus vulnerabilities, so to speak, that existed within that network for Target. After 10 days, they were able to compromise 800 point of sale cash registers for Target across the United States. So one minor little thing can escalate into a giant impact because of all of these small things that seem innocuous. So I always recommend that people do incident response planning because then you start really looking at well what ifs, and you start looking at where these impossible vulnerabilities can become chained together into something that could be a big problem.

Calvin (36:41):
Now that you manage this instance with the infected device, since we’re talking enterprise for example, nobody in the agency that works on a site should be able to do any work from his personal computer. It is just super widespread. I guess at the highest level, there’s probably like mobile device management, but pretty much everybody should ever works. But whether it be a laptop or a workstation that is locked down where they can’t go and install whatever browser extension they want, they can’t install anything that is not essential for working or developing. That site should not be installed and it should be enforced their regular malware scans on local device because this is another entry point, and we’ll probably maybe within the next one or two months, we’ll be releasing a bit of research on that. That is actually a huge, huge problem in the WordPress space where hackers are specifically launching phishing attacks to infect actual local devices, which they then use to steal the workers’ authentication cookies from the browsers and they steal all the cookies, send them off to remote location, then sell them in the dark web. So they’re not selling passwords anymore, they’re selling actual authentication cookies because the cookies allow you to bypass the password checks. They allow you to bypass all two F a. You’re just straight up that user at that point. And if you don’t have proper mobile device management that you just let your employees install whatever and let them work from your personal laptop, that is another huge attack vector there.

Kathy (38:26):
That’s how the last pass intrusion, the debacle, the gift that keeps on giving with that last pass hack. But it happened because of a high privileged developer having access on a personal computer at home and some media plugin or whatever wasn’t updated, and that turned into one of probably historically one of the biggest widest impacts hack that we’ll see in our lifetime. I’m still hearing stories, so yeah, I am looking forward to reading that research. Calvin, you are on it. You’re just like, I am so glad we’re friends because I am into all this stuff, even though I kind of work in more of the empowering users space right now. Security is so fascinating. I love the creativity of hackers, not so much like the malicious crap, but this is creative interesting stuff that pushes the envelope of what we think is possible. But on the enterprise side, y’all listening to this, you’ve got to be aware of this and you’ve got to be aware of all of the different entry points and all of the different ways things get chained together. So I think you should be following Calvin’s work.

Calvin (39:40):
Another big one is having a really solid backup system, and that means that you don’t use the same way with the malware scanning. Don’t use anything that is plug and based at all. Because conceptually, imagine this, if I hack your site, my goal is basically to have my malware running for as long as possible, and one of the easiest way to prevent you from restoring or deleting my malware is making sure that you can’t use your backups anymore. So if you have a backup plugin or anything from within workers that can back up to a remote location, what is preventing the malware from either reinfecting your backup so they can retrospectively if for example, let’s say using Dropbox and the plug-in users, I don’t know, an A P I key for that, and maybe the A P I key also has the permissions to remove backups, and I know many plug-ins that allow you from within the admin dashboard to prune backups or to delete a one-off backup that you took.

(40:48):
So there is the possibility from within the plugin to delete the remote backups, and if that is possible, what prevents an attacker from just deleting all of your backups and then you can’t even restore anymore. That is the worst case scenario. So the same way with the malware in your backups need to come from outside the system, so outside of WordPress so that they can be tempered with, and ideally you should use a storage provider or remote storage provider where the backups are append only. I don’t know if Carlos a w ss, I’m sure they have something like that, but it needs to be a only, you can’t delete backups. They probably have something like that. I mean, right now

Carl (41:33):
For EM, emer, it’s just like the ss, the database server itself gets backed up, so it’s the entire machine. It’s not even the database, so there’s no even a Pandora or whatnot. I mean, you can delete them, but again, you need access to the A W Ss account. So it’s already on the multi,

Calvin (42:00):
You can’t delete it from within WordPress.

Carl (42:03):
No, no. I mean, I wouldn’t allow that anyways. Again, it doesn’t make sense if a lot of what we were talking about, right, why we don’t want to necessarily have WordPress do all the things. I’ve been in WordPress long enough that I don’t want to have does this. Obviously, one of the reasons WordPress is popular is because we have it do everything, and people love that because they could just install plugins and stuff like that, but it’s kind of at least for security as we’re discussing, it’s a bit of theater. It’s mostly theater actually. You don’t actually need to do that much to secure, to be effective at securing your WordPress installation. You don’t actually need a lot of these large security plugins. You just need to be more deliberate in the little things that you do. Like things like what Calvin’s working on, encrypting your data at rest, like using two fa, don’t let people, I have a small security plugin, and all it does is it doesn’t let you reuse passwords that were in Passwordless and basically it won’t let you, if you’re an administrator, it won’t let you log in.

(43:26):
It’ll be like, you need to reset your password or you can disable it and just say it’ll do a warning. But essentially those are little things, right? Principle of least privilege. This is not a thing that you need a plugin to do. You just need password ig, don’t need plugins for that. A lot of it is just, that’s why it’s important what Calvin’s working on, because he’s trying to tackle the things that, okay, this has to be done at the application level, but backups is no, backups is not something I would design a plugin to do. I would just be like, it’s the job of the hosting provider to do it. It’s the job of your, in my case, the emer platform to do it. Or if you’re using spin up, spin up offers backups, they’ll send the backups to, and the only way you’re going to purge those backups is if you have access to the spin up account to go delete the backups there, right? Or you get the SS three key.

Calvin (44:32):
Yeah, or the S three.

Carl (44:33):
Yeah, but the S three key isn’t spin up. It’s not on your WordPress site. It’s more involved. Again, the more it’s about, I think, I dunno if you discuss it, you use that term, but it’s like you Swiss cheese thing, it’s about adding friction. A lot of security is adding friction. If you don’t want somebody to brute force your login, okay, you put limit login attempts. Eventually they can get in if they’re really patient, but you went from, it’s the same thing with the password. They can decrypt the passwords, but there’s nothing fast enough right now to decrypt them. If you use Argon two, you can technically do it. It just takes, I don’t think the earth’s going to exist anymore. The sun’s going to blow up before you have the time to decrypt those things. So that’s the length of time we’re talking about. So it doesn’t make sense for hackers to do that. You’re just adding friction. So that’s the security.

Kathy (45:36):
The job is always to make hackers life. Well, malicious hackers lives a lot harder because what they’ll eventually do is go on to somebody who doesn’t have bars on the window. They’ll just go to the next house. The hackers are going to hack, but you want to make in protecting your assets to make their job incredibly difficult, so it just doesn’t look like a juicy target.

Carl (45:59):
Correct. You don’t want to be the lowest hanging fruit for everybody. You don’t want to be the lowest hanging fruit. Like I said, I deal with nonprofits where in China they’re blocked and stuff like that. If you have state actors or organized crime or things like that where they’re like, okay, no, we want new target you specifically, then you’re at a very strong disadvantage because they’re basically very patient and they will wait. One of the best stories that I love is the Stuxnet story. The Stuxnet is just like, it’s a great, if you can ever read on that, it’s a brilliant story, but it just shows you they will wait. They will wait until it’s like that HVAC story. They will wait until they connect, and then they’re like, okay, it’s go time now, and then they’re off. And then once that’s on, it can go and fast or it can go slow, but they’re just patient and it’s really hard to protect against that. The best you can do is add friction everywhere so that it makes your job harder,

Calvin (47:15):
And that is for targeted text, for non-targeted texts for basically vulnerability is discovered and then somebody just fires off at everywhere beside that they can find there. You just don’t want to be the lowest hanging fruits. That’s also true.

Carl (47:28):
Yeah, because that’s what I talked in my initial talk too, is once you’re on their list, you’re worse off once you get hacked, once you’re worse off, because now you’re on lists that people use to for the bots and everything, which is horrible.

Kathy (47:48):
Yeah, it’s like being on a spammers list. You just not the list you want to be on at all. Well, you guys, this has been a really great conversation, but I know we have to wrap things up. I have another meeting and we have to give Bob a little less stuff to edit, but I think we should have this conversation again in the future, especially as we security, there’s always going to be security events and always things that we can talk about. Calvin, where can people find you online to follow your work?

Calvin (48:18):
So our website is snicco.io.

Kathy (48:27):
And you’re active on Twitter as well as in so many Facebook groups as well?

Calvin (48:31):
Yeah, more or less. Yeah.

Kathy (48:33):
Yeah. And Carl, where can people find you everywhere?

Carl (48:38):
I mean, I am working mostly on emir. It’s emer app.com. I’m still on Twitter. I mean, I’m going down with the ship basically. I’m not on any other social media, but I’m not as active tweeting. But if you tweet at me, I definitely reply and whatnot. But then there’s Carlalexander.ca.

Kathy (49:00):
Amazing. Great. Well, thanks guys for joining me here for this great conversation and we’ll talk to you next time.

Calvin (49:08):
Thanks for having me. Thanks. Thanks guys.