“Can you just install this WordPress plugin?” – Supply chain vulnerabilities and the art of “no”

Most of our clients know that the bulk of our site builds are still based on WordPress, even if that's our own version of it. And that means a world of plugins and themes are available, right? No. Let me explain why...

Development News Opinion

Today I was made aware of this news of WordPress backdoor installations from late last week, and we, as a business, did a quick scan to double check we weren’t affected. We aren’t. We don’t use anything from this supplier.

But it highlights one of the reasons why we’re peculiarly sniffy as a business in the WordPress space. We have our WordPress based Standfirst for Web. It runs a suite of plugins which are 80% ours, and the rest are carefully selected. However, even with our care, we’re vulnerable to supply chain attacks, as any software supplier is, and managing that vulnerability is a part of the service we provide.

What is a software supply chain attack?

It’s rather like any other. Imagine you’re the prime minister, and you have the most amazingly secure kitchen to ensure you can’t be poisoned. However, you publicly state that you love a rare brand of marmalade. So now, to have a chance of poisoning you, all an assassin would need to do is to put a poison in a jar of marmalade on the way to the prime minister’s kitchen. Any security vulnerability in the chain of supply of that marmalade could result in a chance to attack the PM.

And that’s how it is in software. We get a lot of our plugins from wordpress.org who get their plugins from lots and lots of developers who range from professionals in substantial development studios through to hobbyists sharing a solution to a problem they have. It’s all very good. But what happens if that plugin developer is poor at security? What happens if they get corrupted – perhaps they’re desperate for money for healthcare, or some other critical need? It happens. Or what happens if their computer is hacked in order to deliberately inject a weakness into a popular piece of code running on millions of servers?

In the breach linked above, it looks like somebody made use of a weakness in the servers of a supplier in order to inject a backdoor to allow them control over many servers. These backdoors can then ping back, allowing the owner of the code to use that access for whatever means they like, or to sell it to other criminals. Sometimes the backdoors are never used.

How does Interconnect mitigate against these attacks?

We take a number of steps. None are perfect. Security is always a compromise between performance, convenience and cost. But our approach is helpful to keeping our client sites robustly healthy. Unless you’re one of our legacy low budget clients or have had what I call “favour sites” built – i.e. those done at low cost for people we know that wouldn’t normally be in our normal client base, then the following applies:

  1. Temporary cloud servers without local storage – our servers die daily and are replaced using code from our repositories.
  2. Shifting, proxied IP addresses to make it hard for anyone who does somehow breach us to have a fixed IP address to work with.
  3. We review all new plugins and suppliers to ensure they are robust and professional.
  4. All uploads live on a filestore that can’t execute PHP, meaning that there’s no way to get uploaded server code running.
  5. A vulnerability bot scans our codebase and dependencies to check for known problems.
  6. We don’t trigger auto-updates, but wait to find out if updates are safe, so long as they are not for critical vulnerabilities.
  7. Development teams shouldn’t just trust random packages, plugins and libraries from around the internet.

This puts our sites a long way up from a typical WordPress install, making it a lot easier to keep the site in good health. Is it perfect? No. But the cost overheads of authenticating every line of code in a complex stack would be unbearable by most of our customers.

What can I do?

The simplest thing an individual can do to improve their online security is to manage their passwords carefully, use robust passwords, and store them in a secure way using a password manager (all the major platforms and browsers have them now) or use a third party one like Lastpass or Bitwarden for those annoying situations where sharing of online identities is required.

You can also choose providers like us, and make sure to ask questions about the security compromises required. If your supplier says “we are secure” then that’s BS. You need to know how secure because nothing is perfectly secure. There are weak links in every chain, and your supplier absolutely should have an idea of where their strengths and weaknesses are and be open about it so that you can make an informed choice as to whether the compromises taken are appropriate. If you’re one of our customers and wish to check what we’re doing, just contact us and ask.

Leave a Reply

Your email address will not be published.