Advanced WordPress Security: A Discussion with Tim Nash

Robert Abela: Welcome to the MelaPress Show. We do these live streams every Thursday at 4 p.m. Central European Time and 10 a.m. Eastern Daylight Time. Before we start, Tim, I want to share how I first met our guest. I first met Tim about 10 years ago at WordCamp Edinburgh 2015. I was part of the organizing team. It was held at the Skyscanner offices.

Tim gave a talk about the REST API and explained how it would change the world. In terms of experience, Tim has spoken at many WordCamps, contributed to core, organized meetups, and developed plugins. He has a lot of experience in web security.

He is actually launching a web security course. For anyone who has subscribed, please excuse him. He was supposed to upload content today, but had some problems. He still showed up, so please bear with him. According to my friends Nate and Podcast, he is also a “Doom speaker.” So Tim, how are you?

Tim Nash: I’m okay. That’s a pretty amazing introduction. It feels like such a long time ago. Ten years. It really went quickly. That was a very unusual WordCamp. I ended up speaking three times at that one event. I was on a panel and did a lightning talk as well. By the end of it, I was very tired. I had just started a new job.

Just before that WordCamp, I started working with a company called 34SP, a hosting company in the UK. I was really lucky because I got to partly design my own job. I had the title of Platform Lead and Developer Advocate.

A developer advocate basically meant I could travel around the country and do talks. It worked well for the company, too. People weren’t necessarily expecting someone to travel to their local user group.

It did lead to some interesting moments. I turned up at WordPress Preston and the only two people there were me and Mike Little, the co-founder of WordPress. The organizer hadn’t even shown up.

Robert Abela: That’s interesting. It’s not just about business, though. I’ve always said I’ve made some real friends through WordCamps and meetups. Friends I still talk to today.

Tim Nash: I think if I were to look through my closest personal friends, a lot of them came from this community. That’s partly because the WordPress community is quite friendly and open.

We used to have meetups all over the UK. I worked out that I had been to 26 different meetups in one year. Not 26 events total, but 26 different meetups. Each one had new people and its own little mini community. It’s a fantastic way to build around open-source software.

I didn’t actually manage to get to it, but if you come across Tailscale, which is a mesh VPN service, they run meetups for people. There was one in London recently that 90 people attended. Just for drinks. People know they’ll meet others who are at least vaguely interested and probably quite technical.

WordPress is similar, but with a broader audience. You’d go to some groups and find people saying, here’s my laptop, please help me with my WordPress site. But you’d also be meeting peers from other companies. It’s a really good opportunity. It’s sad we don’t have as many user groups as we used to.

Robert Abela: It really is. Especially for someone like me who works from home. Once a month, I need to go to a meetup. It’s at least a social event. You still meet people. Of course, you talk about work, but it’s mostly a small social gathering. Before we dive in, Tim, for those who don’t know you, can you introduce yourself?

Tim Nash: My name is Tim Nash. I’m either a professional Doom speaker, if you’ve ever come to see me speak, or a WordPress security consultant, if you haven’t.

My day-to-day job is helping people harden and improve their sites. I specialize in hacked site cleanups. I also do security reviews, audits, and vulnerability testing for both WordPress sites and codebases, including plugins and themes.

I’ve been using the term “WordPress security” for about five years. But I’ve been involved in security for nearly 30 years and in the WordPress space for well over 20 years. I like to think I can communicate things in a way most people can understand.

That’s why I’ve just started doing courses, which is what we were alluding to before. I’m busily uploading content for that course. Not right now, as that would affect my bandwidth. But after this, I will be uploading.

Robert Abela: Can you walk us through the process of what you do when a customer comes to you and says, “I think my website is hacked”?

Tim Nash: The first thing I do when a client says they think their site is hacked is bring them down and ask why they think that. You’d be surprised how many people come to me saying their site is hacked and leave with the answer that it just needed some TLC.

I once had a client who was adamant their site had been hacked because the word “hello” appeared on every page. It turned out that a developer had left some debug code in. The site was not hacked.

When the symptoms do sound like a hack, such as Japanese SEO spam in Google results, an extra credit card form on the checkout, or a huge spike in server resources, the next step is to look at the traffic access logs. It’s worth spending a few minutes there before jumping to the files.

You might see a lot of traffic going to a random file like a424.php. That gives you somewhere to start. Next, we verify checksums for WordPress core, plugins, and themes. Third-party plugins don’t always have checksums, but some do publish them alongside releases.

If we don’t find anything through checksums, it becomes an exercise in finding PHP files that shouldn’t exist. Once we start seeing one or two, we stop and say: You are hacked. Let’s go into remediation.

Start with the plugins folder. These days, if a site has been hacked and open on the web for a while, you’re almost certainly going to see a folder with a name like “API key” that shouldn’t exist.

You can try antivirus software if you have it. Imunify360 is okay with the latest rules. If you’re using ClamAV, you’ll need custom rules. I have my own set of rules that I load through ClamAV, which speeds up the process massively.

There are times when you’re on hosts with nothing available, and you’re manually going through files. It’s frustrating. Wondering whether FTP or the online file manager is quicker is a real debate.

Once we’ve confirmed the site is hacked, the procedure is nearly always the same: a variation on “new kit and start again.” It sounds terrifying, but it can be done fairly quickly. The important thing is not do what 99% of people do, which is find one file, delete it, and declare the problem solved.

Robert Abela: Do you try to trace back what happened? If you just delete one file and there’s a backdoor, they’ll recreate access.

Tim Nash: Even with a thorough log analysis, you’re probably still going to miss some backdoors. What I often find is that sites get compromised, a backdoor is placed, and then nothing happens. The bad actor leaves the site for a period of time to see if the backdoor is discovered. If it isn’t, they’ll likely sell the access rather than exploit it themselves.

At that point, the next person comes along and places their own backdoor. The original bad actor may have sold access to multiple people. As a result, you’ll often find multiple backdoors on a compromised site.

Even if you found what you thought was the backdoor, it probably won’t be the original one. Smart attackers leave backdoors in place for at least 28 days. That’s the average log rotation period, so the original entry won’t appear in the current logs.

What logs show you is what’s being exploited and which files are being changed. What you won’t easily see is actions taken through WordPress itself.

A common technique is for a bad actor on an e-commerce site to create a customer user account and quietly add administrator capabilities to it. The lazy ones give themselves the administrator role directly. The sneakier ones add just the capabilities and keep the account looking like a normal customer.

That’s where something like an activity log plugin is useful. You can see that a user shouldn’t be able to install a plugin, but that they just did. If you also have alerting set up, you get notified in real time.

For most people, though, the cost-benefit of a full log analysis doesn’t make sense unless we’re seeing repeated offenses. I’m much more in favor of wiping all files and rebuilding from trusted sources than trying to cherry-pick individual files to delete.

Robert Abela: That’s a very good point. It’s important when doing this kind of analysis to have multiple log files to work with. One solution is never the answer. You have the plugin log, the access log, and the error log. Most backdoors aren’t well-written, so you often see a lot of errors appearing.

Robert Abela: So, when you say you restore the website from a reliable source, what do you mean? 

Tim Nash: I mean, literally going back to the source. Not restoring from a backup. Most people think of backups as the solution. Backups are important, and you should take good ones. But they’re not useful for security in most cases.

There are times when you might need to restore from a backup. If you’ve had a ransomware attack and you’re completely locked out with no way forward, you may need to rebuild from scratch. Starting from a backup to at least get the database is valid.

But what I mean by trusted sources is going back to the original providers. We list out the plugins on the site and then download each one fresh from its original source. If it’s from WordPress.org, we download it from there or one of the other distributions we now have available. If it’s a premium plugin, we go to that vendor’s site.

Custom code is a more complex problem. Hopefully, that custom code lives in version control separate from the site. If it does, we can pull it down and trust it. If the code only ever existed on the server itself, we need to isolate it and ideally do a code review before putting it back.

That scenario usually involves themes rather than plugins. Someone downloads a theme from WordPress.org or ThemeForest, installs it, and then directly edits the CSS rather than creating a child theme. So when we try to restore with a fresh copy, the client says, “But it’s blue now.” You then have to rebuild the customizations the right way.

Never restore from backups. Even if you restore from a week ago, the vulnerability is still there. And since backdoors can sit undetected for 28-plus days, you’re likely restoring the backdoor along with everything else.

For an e-commerce site, you can’t lose two months of data. So you do need to work with the database carefully. But don’t restore the files from backups. It’s not a good solution.

Robert Abela: That’s a very good point. You might restore an already-hacked version of the site. There have been big companies that took six months to realize their site or application was compromised. If you have six months of backups, all of them are likely tainted. What are the most common sources of hacks you see?

Tim Nash: By far, the most common reason every site gets hacked is because people haven’t kept things up to date. The root cause is almost always a plugin or theme with a vulnerability that has already been patched. The irony is that when a vulnerability is discovered and patched, a new version is released. Plugin developers rightly tell people it’s a security release. But bad actors can read those announcements too.

There are bots that trawl through looking for the phrase “security update.” And building proof of concepts has become much faster and easier. That’s one area where AI has genuinely changed things.

We used to measure the time between a vulnerability announcement and an active exploit in weeks. A couple of years ago, I was saying you had a couple of days to update. Now, for popular plugins, if there’s a way to exploit it, that window is measured in hours. Sometimes, even daily automatic updates aren’t fast enough. But keeping things up to date is absolutely the best way to avoid being hacked.

Robert Abela: It’s almost instant nowadays. We see it in our own support requests. We ask what version someone is running, and sometimes they’re on plugins that are two or three years old with 15 or 16 updates since. Even from their own security vendors.

Tim Nash: I saw one site that had 89 plugins. The oldest one was eight years out of date. Of those 89 plugins, nine had been closed by WordPress.org for security issues. The scariest part? That site wasn’t actually compromised. They were just very lucky.

Robert Abela: It’s more a question of when it’s going to happen rather than if, right? When you’re doing your risk assessment as a company or organization, you really do have to start from that basis. You should be asking yourself: when we get hacked or when we have a service continuity issue, how are we going to cope? If you do the prep work early, you’ll save yourself a lot of headaches. If you’re trying to think through everything while you’re panicking, it’s already too late.

Tim Nash: Exactly. You need to know what’s running on your site. That’s the idea behind a software bill of materials. You need to know what plugins you’re running and where you got them from. You’d be amazed at how many people don’t know where their plugins came from.

Sometimes a developer installed it, and that developer left years ago. Is it your license? That’s where things get complicated.

Robert Abela: We see it constantly in support. People don’t just know where the plugin came from. Some don’t even know why it’s there.

This highlights how important a disaster recovery plan is. I used to work as a systems engineer at a big software company. We had a disaster recovery plan. I used to make fun of it because we had to document everything. But when we were hacked, you realize just how effective it is.

I’m not saying every WordPress website needs a fully documented enterprise-level disaster recovery plan. But you should have some kind of repository or document. Even just a list of the plugins you’re using. At least then, when you’re panicking, you have a starting point.

Tim Nash: Security is less about tools than most people want it to be. People prefer to make it about tools because that gives them something to install, configure, and then forget about. So much of security is about process and people.

Documenting things, as boring as it is, matters. Look at compliance standards for inspiration, but you don’t need to go that far. Just think about the basics. How do I take a backup? How do I restore it? How do I know the backup is good?

When you start thinking in that mindset, the next step is just jotting it down somewhere. The ultimate goal is a simple standard operating procedure. It’s just a recipe. Step one, step two, step three. Here’s how I take backups. Here’s how I restore them.

Once you get in the habit of writing things down, everything gets better. It means you can go on holiday. There are so many system administrators who can’t take a holiday because they’re the only person who knows how anything works. Or they go on holiday with both work laptops and phones because they’re terrified to leave the site unattended.

Having documentation gives you and those around you confidence. And oddly, if you do write things down and create these policies, you often never have to use them. The act of writing it out makes you already more positive and proactive, and things improve along the way.

When I used to run a company, our insurance company asked for our policy in case of floods. We were in Leeds, about 100 metres from the river, which was also about 30 metres down. We dutifully wrote the policy. As a joke, we also included a zombie invasion policy. Notes came back from the insurance company saying our zombie invasion policy wasn’t up to standard.

You can have a bit of fun with it, but there is a serious purpose. Document some of it. Be simple if you prefer. Use plain words. Describe what’s happening as simply as possible.

Robert Abela: These things are very important. Accidents happen, hacks happen, and mistakes happen. At a previous job as a systems engineer, we had a SQL database server and a small NAS with SCSI RAID drives. We needed to change the format, and in the process, accidentally pulled out the OS drives and formatted them. Then we wondered why the server wasn’t responding. You don’t need a hack for things to go wrong.

Let’s look at the hardening aspect. Security is not just a one-click solution. It’s a continuous process, especially as your website changes, adds functionality, and your team grows. It’s not a static plugin install. For someone who is new to all of this, what are the basic steps they should start with?

Tim Nash: Step one is to buy WP Security 101. When the course is available, that is clearly the first step.

But before we get into specific tactics, you need to understand your threat model. For most WordPress sites, the threat model is automated attacks. Very few sites are hacked because of who the site owner is or what content is on the site. The vast majority are compromised by automated attacks looking to exploit resources.

So our first step, assuming we’re not running anything mission-critical, is to turn on automatic updates. I know that gets a boo and a hiss from many people. But if you’re starting from scratch and don’t know what you’re doing, automatic updates mean you will actually receive updates.

There is a chance things will break. But things can break anyway. If all you’re doing when you manually update is clicking the button and then walking away, there’s no benefit to pressing it yourself. Most people’s version of “testing after updates” is visiting the homepage and saying it looks fine, then wandering off. If that’s you, just turn on automatic updates.

There are smarter, fancier updating solutions that include automated testing before and after, with backups in between. But if you’re brand new to this, start with automatic updates.

The second thing is to install a two-factor authentication plugin. If you’re the only person on the site, the two-factor plugin by the WordPress Security Contributors team is the one I’d recommend. But if you need to enforce 2FA for multiple users, that plugin won’t do it automatically.

If you want to enforce it, the Melapress WP 2FA plugin lets you select enforcement by roles. That means you can blanket-require it for your entire team. Even if they choose email as their 2FA method, with automatic updates and 2FA in place, you’re already 99% better off than most sites.

If I were allowed a third step, I’d say force people to use long passwords. WordPress will warn you that a password is weak, but it will still let you set it. Enforce a minimum of 16 or 32 characters. Then you’re in a really good position, and you can start layering other things on top.

Robert Abela: That’s a great point. Earlier this year, Patchstack and Sucuri co-released a report, and the top two most common threats were credential issues, such as weak passwords and a lack of 2FA, and outdated software. Doing just those two things puts you way ahead. There are other solutions, like firewalls that have their place, but if you start with those two, you’re already well protected.

Speaking of the extra stuff, let’s talk about firewalls. Hot topic: plugin firewall or proxy online service?

Tim Nash: Neither, honestly. There are pros and cons to both. If someone comes to me and already has a WordPress security or firewall plugin installed, I’m not going to tell them to remove it. But I will ask them: is it providing you with nice, warm, comforting feelings? If it is, keep it. Because that’s about all it’s really doing.

That’s a bit harsh, but it’s accurate. When I worked for a hosting company, we found that you were just as likely to be hacked whether or not you had one of the WordPress firewall plugins installed. The type of hack was slightly different, but the compromise rate was the same.

A web application firewall via a proxy, like Cloudflare, is much more effective. It’s doing preventative work against bad bots and bad traffic before it even reaches your server. Cloudflare is a reasonable thing to have in front of your site.

These WordPress firewall plugins, such as Wordfence, aren’t traditional WAFs. They’re closer to virtual patching. If you’re using a free version with a 14-day delay on rule updates, it’s essentially worthless. Think about it: 14 days with no updated rules means the protection is already outdated.

If you have a client who genuinely can’t keep things updated for some reason, then a firewall plugin is a last-resort shield. But generally, I’m not in favor of either option as a primary security strategy.

What I do favor is server-side security. If you’re using something like ModSecurity with a modified OWASP top 10 ruleset, that’s much better. It’s catching common threats without WordPress being involved at all.

The other reason not to rely on a WordPress-side firewall is timing. By the time the plugin does anything, the bad actor has already triggered something in WordPress because the request already reached the application. The threat is already inside the server before the plugin can act.

One of my favorite examples: most of these firewall plugins place a file called WAF.php in the WordPress root folder. It takes whatever is in your PHP pre-append and puts it there. That file can’t be scanned by the plugin because it has no idea what should legitimately be in there. So the best place to hide malware is inside the WAF file itself.

Robert Abela: That’s a great point. If the plugin firewall is triggered, the request has already reached your server. It’s already at the application layer. That’s a fundamental difference compared to having a proxy in front.

So the basics are: keep software up to date, use strong credentials and 2FA. That covers you well. Let’s go a bit more advanced.

A small plug for your course, wpsecurity101.com. In one of the chapters you talk about browser security and security headers. Can you explain what security headers are and how browser security fits into the bigger picture?

Tim Nash: Security headers and browser security are essentially a WAF inside your browser. The website sends a set of headers telling the browser what it’s going to do and what it expects to be happening.

If the site does anything outside of those declared behaviors, the browser should block it.

The first important one is the HSTS header, which stands for HTTP Strict Transport Security. It tells the browser: never load me over HTTP, always use HTTPS. Most headers include a command and an expiry time.

You can break a site with HSTS if you’re not careful. There’s a parameter called “include subdomains.” If you set HSTS on example.com and include subdomains, then for the next year the browser will automatically redirect any HTTP request to HTTPS, even for subdomains it has never visited before. That’s fine until you set up a dev subdomain and forget to install an SSL certificate.

There are many variations of these policies. Individual headers have evolved into broader containers. The big one is the Content Security Policy, or CSP.

In a Content Security Policy, you declare what resources your site is allowed to load. You can say images should only load from your own site and one other specific domain. If the browser sees an image request from any other domain, it simply won’t load it.

For images, that’s not so critical, but for JavaScript, it’s extremely powerful. You can say JavaScript from evil.com should never run on this page. You can set this policy site-wide, or just for specific pages like the checkout.

You can go even further with nonces, which are one-time tokens that prove the server generated a particular piece of code. Or you can use SRI hashes. If the hash doesn’t match, the browser won’t load the resource. That means if someone has injected malicious content into a script, the hash will fail, and the browser will refuse to run it.

The problem is that building a good Content Security Policy is painful. What usually happens is that people set up a CSP that allows everything. They’re just trying to tick a compliance box.

If you have YouTube videos on your site, it becomes extremely complex. Loading a YouTube video doesn’t just load one script or one iframe. It loads a dozen scripts and a dozen iframes, often from different Google server addresses. If you’re using Google Ads, it’s nearly impossible to lock down properly.

The WordPress admin area is just as difficult. So much of it uses inline scripts. Plugin developers often write JavaScript directly in the footer, which means you can’t verify it with hashes or nonces.

It’s a pain, but if you can get it working for your site, especially if you handle anything sensitive, it’s absolutely worth doing.

Robert Abela: I remember when I worked as a systems engineer about 15 years ago during the early days of CSP. Setting up those policies took hours. Back then, it was called P3P. We had CDNs, firewalls, and all sorts of things to integrate.

And especially now with things like YouTube, finding the right addresses or subnets can become really difficult. Since we’re talking about browser policies, this naturally leads to the weakest link, which is the user.

Robert Abela: Everyone makes mistakes. Even less technical people can put your website at risk. As a team grows, it’s natural. Most team members don’t need admin access. But a store manager might have access to stock, prices, and orders, and they can make mistakes too.

You mentioned enforcing 2FA and strong passwords. What are the best practices for non-technical users? How can we help them help us keep our own websites secure?

Tim Nash: The first step is to help them by reducing what they can do. You mentioned the store manager role. In practice, I very rarely see someone who’s actually been given the store manager role. They almost always get the administrator role.

So the first thing to do is go and actually assign the right role. Give them the store manager role and take away access to everything they don’t need. That reduces the threat surface for them right away.

Then we can use both a carrot and a stick. We want them to use 2FA. The best way is to enforce it. But we should also make it as painless as possible.

I’d love everyone to use an authenticator app or a hardware token, but pragmatically, if they use email 2FA, that’s fine. If they use SMS, that’s okay too, as long as they’re doing something. Same with passwords.

We can’t force anyone to use a password manager. But we can make it harder by enforcing password length. I’m in favor of length rather than complexity. A long, unique password beats a complicated but short one.

I’d much rather you have a totally random 32-character string stored in a password manager than something short with special characters. The important thing is the length. 32 characters is ideal. 16 characters is about the point where a human can realistically remember something. 

That’s probably your sweet spot for people who refuse to use a password manager. Forcing a 16-character minimum and 2FA helps enormously. But the biggest thing is simply telling people about the risks. Show them what your security emails look like. Tell them: if you get something that looks like this, come and talk to us first before clicking anything.

As the person enforcing policies, you also need to show users exactly what every step of the process looks like. If you don’t do that, you shouldn’t be surprised when they get phished.

Robert Abela: You’re right. And you’d be surprised. Even very experienced people can fall for it. A few months ago, Troy Hunt, who is one of the leading voices in web security and has even spoken in front of the US Senate, had his email service account hacked through phishing.

It can happen to everyone.

Tim Nash: I had a colleague who was on the phone with a client, glanced at an email, and clicked it. I was watching and said, “Stop.” He looked back at the email carefully and realized he had just clicked a phishing link. About two seconds later, the legitimate email he had been waiting for arrived. He had simply clicked the first email he saw.

This was a person who used to train others on spotting phishing emails. It will happen to everyone eventually. We’re in a world where phishing emails used to be easy to spot because of spelling mistakes and strange grammar. But bad actors have learned to use tools like ChatGPT to clean up their writing. The emails are getting much better.

Robert Abela: I’ve noticed that too. Our marketing team has been forwarding some suspicious emails lately, and some of them look genuinely convincing. Correct spelling, good grammar, and professional tone. They’re clearly using AI to improve the quality.

Tim, there’s so much more I’d like to discuss, but we need to start closing. Is there anything important you’d like to share before we wrap up?

Tim Nash: When we talked about layers, I mentioned automatic updates as the first layer and user security as the second. The third layer is monitoring.

You need some kind of user-level monitoring, as well as an understanding of what your server logs are showing. Even if you’re not going to dig through them yourself, you should at least know where they are so someone else can access them.

If you are technically minded, set up alerts for three things: a plugin has been installed, a plugin has been deleted, and you have logged in to your WordPress site.

That last one is really useful. When you wake up in the morning and see a login notification from Peru, you’ll immediately know that wasn’t you. Just those three alerts on their own will help you identify so many potential signs of compromise.

Don’t go overboard and add lots of alerts. They become noisy, and you’ll stop reading them. Those three combined should be enough to catch the critical issues without overwhelming you.

Robert Abela: That’s a great point. We get asked all the time which notifications to enable. As you said, the obvious ones are plugin installs and logins. But there are many cases where you, as the website owner, know your users best. You know when they should be logging in, from where, and what they should be doing.

I was guilty of enabling too many notifications in the past. You get so used to them that you stop paying attention. And then you miss the one that actually matters.

Robert Abela: Thanks a lot, Tim. Where can people find you, get in touch with you, or hire you?

Tim Nash: You can find me at timnash.co.uk. I’m available for hire. You can also find the course at wpsecurity101.com. I do social media, but I do it really badly. You can occasionally find me on LinkedIn and Blue Sky. I also have a Mastodon account at [email protected].