How do Websites Get Hacked – Software Vulnerabilities

Screnshot of hacked website

In the first article in this series I gave some background information on the scale of cyber-crime and looked at the different ways hackers can steal your usernames and passwords.

Theft and misuse of usernames and passwords is one of three principle ways websites get hacked. The other two are:

  1. Software vulnerabilities
  2. Third party software integration

Today I will cover software vulnerabilities

Different Types of Vulnerability

Broadly speaking there are two types:

  1. Known vulnerabilities
  2. Unknown vulnerabilities

But how does software come to have vulnerabilities? The glib answer is because software is written by humans and humans make mistakes.

But we must go deeper.

A Hacker looking at a laptopDifferent mentalities are involved here: a hacker’s mentality is completely different from a software developer’s. The software developer is focused on how to make things whereas the hacker is focused on how to break things.

Therefore, despite all the new and emerging processes encompassed by methods such as DevOps that help to make software development more error-free and secure, there will always be a hacker whose purpose in life is to find weaknesses in code and exploit them for their own financial gain.

And that creates the everlasting cycle: software development, vulnerability exposure and vulnerability fixing.

Software development is a never-ending process!

1. Known vulnerabilities

Vulnerability sccannerSo let’s look at known vulnerabilities first.

A proper software development process includes code audits and extensive testing. I referred to DevOps earlier: this is a method that includes the use of tools built up over time that test for, and highlight, vulnerabilities and coding errors in newly written software code so these can be fixed before the code is released.

DevOps type processes are increasingly being used in software development, especially in well-established organisations or projects, so the quality of newly released code is improving all the time.

But the testing protocols in these tools are developed by humans and built up over time as experience grows. So, although they are getting better, they are not yet perfect by any means.

I remember the days, 12 or more years ago, when a WordPress update caused everyone to hold their breath in case it crashed their websites. No longer, thanks to improved, automated testing processes.

However, the same rigour is not always followed by plugin developers, some of whom are single individuals, enthusiastically writing plugins to meet specific needs that they or their customers want.

All applications will contain errors and vulnerabilities, but these applications probably more so.

In the case of the single enthusiast who has written a plugin and released it to their users, a vulnerability may be discovered after the plugin was made publicly available.

When this happens, the discoverer will tell the developer so the developer can fix the problem. After which an update (also known as a security patch) will be released.

So a known vulnerability is one where the software has been available publicly, a vulnerability has been discovered and reported to the developer and a software update released.

The problem is that not all users will update the plugin on their websites.

So the software vulnerability, which was contained in version 1, but fixed in version 2, is now known by everyone – including the hackers.

And the hackers now know exactly what to look for (Websites running version 1 of the plugin) and how they can exploit the vulnerability.

That’s why it’s so important to implement updates (security patches) as soon as they are available..!

2. Unknown vulnerabilities (zero day)

An unknown vulnerability, also called a zero-day vulnerability, is one that no one knows about – yet!

These are many times more dangerous than known vulnerabilities. Here’s why:

If a hacker discovers an unknown vulnerability before ‘the good guys’, the hacker has no reason to report it. Instead they will exploit it as much as they can before a fix can be released.

There is no protection against an unknown vulnerability and the only constraint on the hacker is how much damage the vulnerability will enable them to create.

There are many instances where plugins containing unknown vulnerabilities have been exploited to cause a lot of damage among WordPress users.

A zero day vulnerability timelineSome of these zero-day attacks took place over a period of up to a week before a fix was released. When you consider that hackers use bots (automation) to search for and infiltrate vulnerable websites, you will see that they can affect many thousands of websites very quickly.

How to protect your website against software vulnerabilities

In the broadest sense there are three things you can do to increase the defences of your website:

  1. Always keep your software up to date – at the very latest version
  2. Reduce the access points (or footprint) within your website as far as possible
  3. Deactivate and remove ‘at risk’ plugins from your site

Plus, a further thing you should do to enable a quick recovery when your site has been hacked:

Take regular backups of your website: at a minimum once a week but also after any content or other changes you make, and store them anywhere but on your server.

Let’s look at those a bit more closely:

1. Keep all your software up to date

In WordPress terms this is very straight-forward: log in to your website every day and check for updates:

WordPress admin screen showing updates available

Whenever you see that little round bubble against the ‘Updates’ menu item go straight there and do the updates.

An old habit that has died very hard with me is the order in which updates should be done, if there are updates for themes, plugins and WordPress itself: I always do the WordPress updates last.

The reason for this is that, at least in the bad old days, some plugins (or themes) that had not been updated to work with the latest version of WordPress, caused the site to crash when WordPress was updated.

There’s nothing you can do if the errant plugin still has not been updated, but where both a plugin update and a WordPress update are available, I always do the plugin update first.

2. Reduce the footprint in your website that’s available to hackers

What I mean by this is to do things that will minimise the damage a hacker can do if they do get access to your website. (And you should assume that at some point they will)

In this article I described the different user roles within WordPress and what each role enables its user to do.

The lower the user role, the less they can do.

Nasty message from a hackerBy keeping the user roles of the people who access your website at the lowest possible level, but one that still allows them to do what they need to do, you are restricting the foot print available to a hacker who gains access through one of their logins.

Even if you are the only user on your site, it’s still worth creating a second login for yourself – one that enables you to add content but not to edit site settings and do the other things an Administrator can do.

You still need your administrator login, but you should use this as little as possible to reduce the risk of a Man in the Middle attack picking up your log in details when you’re working in Starbucks.

You will still need to log in each day as an Administrator in order to check for and implement updates, but only do so in a safe location – not in a coffee shop!

When you’re in the coffee shop log in as an Author to do your content updates. Then if a hacker intercepts your login details they are limited in the damage they can do.

There are a number of other steps you can take that involve editing the wp-config and .HTACCESS files on your website, checking file permissions, hiding your login page and more. You should have a developer do this for you, unless you are comfortable editing those files.

Do be careful, though: a mistake in either the wp-config.php or .HTACCESS files can bring your site crashing down..!

3. Deactivate and remove insecure plugins from your site

Here’s what I mean by this: keep an ear to the ground and your eyes open for any news that a plugin you’re using has been discovered to have a vulnerability, but for which a patch is still being developed.

When you find one of these you should deactivate and remove it from your site. Why remove it..? Because even deactivated plugins can be hacked.

Once the patch has been released and the plugin is safe again you can restore it to your site.

Taking backups of your website

Disks being backed up in a safeYou must work on the assumption that your site will be hacked – at some point. With this in mind you need a recovery plan, and the basis of your recovery plan is having a clean backup of your site.

With a clean backup of your website you can simply delete the hacked site entirely and restore the site from the latest clean backup. This is the safest and quickest way to recover from a hack.

But it does require the discipline of checking the site each day (so you find out as soon as possible when it has been hacked) and taking regular backups. Letting scheduled backups run without also checking your website each day could result in you backing up and then restoring a hacked version of your site.

Which doesn’t help anyone..!

Putting it all together

So what are we saying here – it’s quite straightforward really:

  1. Check your site each day for updates – whether of plugins, themes or WordPress itself – and implement them
  2. Do any updates as soon as they are available
  3. If you read or hear about a plugin that has a vulnerability which has not yet been fixed (zero day) deactivate and remove it from your site until a fix is available. (Even a deactivated plugin can be hacked)
  4. Take backups of your site at a minimum once a week but also after any content or site updates and store them off line. This will enable you to recover quickly from a hack. Here is some information on the backup plugin I use.

Is your WordPress website as secure as it could be? Take a look at the WordPress security products I have reviewed (I use all of them):

Stay safe!

Martin Malden