Having your very own website used to be something reserved for developers once upon a time. All that changed with WordPress, and for the better.
But it’s never over.

Whether you run a small blog with a loyal following or a big e-commerce window, your website is an integral part of your life. It represents your passions and reflects your abilities.

Being hacked takes away from you the power to share your best with your readers or customers. In some cases, the damage to your site may be too deep for you to get your site back up with all the data.

And the worst part is that it looks like a senseless act, especially when your website has no information worth stealing.

This is why we’ve compiled a list that we hope you, a site owner, gain some insight into:
Why hackers hack your site, how hacks cause so much damage, and some common attacks along with real-world examples of those attacks.

Why hackers hack your site

While some hacks are aimed at gaining information from your site, most attacks are to accessing your hosting and database servers. If accessed, files on your website’s server could provide to anything from yielding sensitive information, to unlimited access.

Where vulnerabilities are found and how to protect your website

Most vulnerabilities are found in plugins and themes. Keeping them up to date, or deleting ones that you don’t use, is one way you can protect your website, and server.
There are other ways you can keep your website safe though. We’ll talk about them in another post.

The types of hacks

One thing you need to know, is that by knowing the kinds of attacks out there, and parts of your site design you have to pay more attention to, you understand how to stay more secure. However, hacks happen in a number of ways and can be difficult to categorize and understand.

That’s what this two-part series is aimed at helping with. We’ve tried to present a lot of information, in a format that is easy to understand. Hopefully, it helps even those of us who aren’t very fluent in code.

In this part, we’re going to talk about:

1. Arbitrary/Remote Code Execution (one of the most powerful ways to take control of a site)
2. File Inclusion-
   1. Remote File Inclusion
   2. Local File Inclusion
3. Injection attacks-
   1. SQL Injection attacks
   2. Cross-Site Scripting (XSS) attacks
4. Backdoors (remember this: it’s how websites keep getting reinfected)

Now that we’ve got all of that out of the way, let’s get down to business.

1. Arbitrary / Remote Code Execution attacks

In an ideal scenario, only trusted code associated with your WordPress site can be run on your site/server. The Arbitrary Code Execution (or Remote Code Execution) exploit though, allows hackers to run unauthorized code on your server. Arbitrary Code Execution is dangerous because it allows attackers to take complete control over the website, or the server it’s hosted on, or both.

How the attack works

Attackers first need to get the executable code to your website. Vulnerabilities on your website, like the ones that allow File Inclusion (more on this below) lets them do this. They then run it on your server remotely.

A real-world example of an attack exploiting the Arbitrary / Remote Code Execution Vulnerability

Vulnerability	Arbitrary Code Execution
Locations and version(s) with vulnerability	WP Super Cache: <= v 1.2
W3 Total Cache: <= v 0.9.2.8 and below
Current version(s)	WP Super Cache: v 1.4.8
W3 Total Cache: 0.9.4.1

WP Super Cache and W3 Total Cache are both plugins designed to cache dynamic WordPress pages in order to reduce the sites’ load times for visitors. Plugins like these sometimes use special tags to differentiate static content from dynamic content. Dynamic content is executed on the server.

The problem with this was that WP Super Cache, and W3 Total Cache had vulnerabilities that could be exploited when websites using them, also used comment fields. You see, these vulnerabilities allowed website’s visitors to post comments with (dynamic) PHP code inside special tags.
Since these special tags were executable, attackers used them to run arbitrary commands, knowing that the plugins would execute them. As a result, the comments would return whatever information the attacker requested.

Note: The next few sections will use the terms ‘remote’ and ‘local’. The best way to explain these terms, would be with reference to the hosting server.
You see, a hosting server is a lot like your computer.

• Anything on the computer/ hosting server is local (like a local file, folder, or drive).
• Anything from outside the computer/ hosting server (like an external hard disk), would be remote.

2. File Inclusion attacks

a. Remote File Inclusion attacks

Most of the time, attackers need to ‘include’ a hack file to your website’s hosting server before they run it. If the vulnerability on your site allows for the file to be included from a ‘remote’ location, it’s called Remote File Inclusion.

How the attack works

Remote File Inclusion is a type of vulnerability that allows an attacker to request your website to include a remote file, which usually consists of executable code. (PHP files are an example). Once your website processes the request and includes the file to your server, the attacker executes the code remotely. (This is why we explained Arbitrary Code Execution first).
Once the attacker does this, depending on what the included file was created to do, it can cause data-theft, or other serious damage to your site.

A Real-World Example of an attack exploiting the Remote File Inclusion Vulnerability

Vulnerability	Remote File Inclusion
Locations and version(s) with vulnerability	TimThumb: v 1.10 to 2.0
Current version(s)	The developer of TimThumb no longer supports or maintains the plugin

Attackers exploited a vulnerability on the TimThumb plugin to first perform Remote File Inclusion, and then Arbitrary Code Execution. And even when the vulnerability was patched in version 2.0, this plugin was so widely used, that it caused millions of sites to be hacked. Even today, we see hacks because of it.
TimThumb let users import images from image-hosting websites (like flickr.com and imgur.com) and edit them on the fly, especially to make thumbnails. The plugin had a list of trusted websites, and only URLs that came from websites were accepted. This process of allowing access based on a list is called ‘whitelisting’.
The problem with TimThumb though, was that it didn’t check the actual source of the file; only checked for URLs that looked like they came from a trusted website.

Here’s a brief explanation of what the plugin did:

Once the plugin accepted URLs that linked to an executable PHP hack file, the file got included remotely to the website’s server. Attackers could then run it, and cause massive damage.
*Disclaimer: None of the URLs or file names in the example are real; they’re only used to illustrate the example.

b.     Local File Inclusion attacks

The Local File Inclusion vulnerability is somewhat similar to Remote File Inclusion, except that it includes ‘local’ files. Attackers could also use this kind of file inclusion as a prelude to executing Arbitrary Code.

How the attack works

This vulnerability allows attackers to access files on the hosting server, that aren’t typically available to the regular visitor. Such files can be used to get admin access, steal confidential data etc.

Let’s say your site allows users to access website files through URL parameters. This is one bad way to have coded your site:

<?php include($_GET[‘file’]); ?>

The logic used to write this command is bad the user can enter any filename into the URL parameter. If your WordPress site has a file with this name, it’ll get executed.

Since our bad code is including files without validation, an attacker can use it to access sensitive files (like passwd file):

http://example.com?file=../../../../etc/passwd

Attacks that employ exploits like these, are called Local File Inclusion attacks.

A real-world example of attacks exploiting the Local File Inclusion vulnerability

Vulnerability	Local File Inclusion
Location and version(s) with vulnerability	Ultimate Member: < v 1.3.64
Current version(s)	Ultimate Member: v 1.3.68

Ultimate Member is a WordPress plugin that makes it possible for visitors to your site to sign up and to create user profiles for them. The plugin exhibited a vulnerability in July this year, when it incorporated user-supplied input in the ‘page’ parameter without proper validation. This allowed for anyone who had access to the membership form to retrieve some sensitive information from local WordPress PHP files.

3. Injection attacks

All websites require user inputs, whether it’s for logging in, or even just to go to the next page through a click. When a website allows visitors to enter inputs, hackers can introduce code to attack the website, or its server. Exploits that follow this method, are known as Injection attacks.

There are many different kinds of Injection attacks, but a couple of the most rampant ones include SQL injection (which allows access to your website’s database through MySQL commands or queries), and Cross-Site Scripting.

a.     SQL Injection attacks

This Injection attack exploits text fields that allow users’ entries. The reason this attack is so dangerous, is because SQL commands could be used to add, modify or delete data on your WordPress’ database.

How the attack works

Every one of us has seen the WordPress login page– you enter your username and password to access the dashboard.

Suppose your username is ‘admin’ you enter it in the login form.

(Just to be clear:  if your username in real life is actually ‘admin’, we recommend that you change it immediately for security reasons).

This input is then looked up in the database to check if such a user exists. The thing is, instead of a valid username, you could also input some SQL code.

Now if, for some reason the website directly used the dangerous SQL while looking up the user, the site could be exploited. Fortunately, core WordPress takes extreme care to make sure that user inputs are sanitized before being used while accessing the database. Various themes and plugins, however, sometimes don’t validate input, thus leading to an exploit.

Again, the modifications that could be made to your database are innumerable, and the results depend on what is modified. Here are a couple of a generic examples of how an attacker could carry out SQL injection, and why it would be dangerous:

Here’s another example of SQL injection (this time in code)… Suppose we input ‘admin’ in the following code:

The following code would be executed:

So just imagine what would happen if you entered:

(cue: violin screech from Psycho)

This goes to show you need to have a lot of checkpoints to make sure your plugins are safe. You can never be sure enough.

*Disclaimer: Again, code in the example above isn’t something you could execute. It’s just there for illustrative purposes.

A couple of real-world examples of attacks exploiting the SQL injection vulnerability:

Vulnerability	SQL Injection
Locations and version(s) with vulnerability	Booking Calendar: v 6.2
Yoast SEO: < v 1.7.3.3
Current version(s)	Booking Calendar: v 6.2.2
Yoast SEO 3.4.1

1. Booking Calendar is a WordPress plugin that was used for making online reservations based on availability. Unfortunately, just a couple of days ago, an SQL injection vulnerability was discovered on this plugin. The vulnerability allowed an attacker to view data from websites’ servers’ databases. Fortunately, the vulnerability was revealed to the developers of the plugin before anyone else, and they fixed it in an update.
Note: If you’ve got this plugin installed in a theme, or it’s on your website as a standalone plugin, we ask that you update it immediately.

2. Yoast SEO is one of the most popular SEO plugins for WordPress with over a million installs.
Versions before 1.7.3.3 had a SQL vulnernability issue. This issue existed in spite of the plugin actually taking measures to protect against SQL Injection. This was because the authors of the plugin made use of a WordPress function called ‘esc_sql()’, which opened a doorway for the vulnerability. So the plugin wasn’t foolproof.

b.    Cross-Site Scripting (also known as XSS)

Cross-site scripting usually affects web applications, when user inputs are directly included as part of web pages.

How the attack works

Web browsers usually have a set of rules to make sure they’re safe from attacks like Cross-Site Scripting. Those that don’t have such rules in place though, have vulnerabilities that allow hackers to inject malicious Javascript.
This means if you’re an admin of a WordPress site, attackers could use XSS to get access to your cookies, or login information, or even just change the content on your site, without you even knowing it. Your sites’ visitors seeing that page via a vulnerable browser would get affected too.

A real-world example of an attack exploiting the Cross-Site Scripting vulnerability

Vulnerability	Cross-Site Scripting
Location and version(s) with vulnerability	Jetpack: v 3.0
Current version(s)	Jetpack: v 4.1.1

Jetpack, again one of the most popular WordPress plugins available, offers WordPress.org users the ease-of-use that WordPress.com users enjoy.
Jetpack version 3.0 had a vulnerability that allowed attackers to send WordPress admins a link, that would execute malicious JavaScript.
More recently though, the Jetpack plugin had another XSS vulnerability, that was patched in version 4.0.3.
See, the plugin analyzed HTML code looking for things like video links that it could embed in the page automatically.
Unfortunately, the plugin didn’t check if video links were also surrounded by malicious HTML tags. The vulnerability allowed an attacker to include executable, malicious JavaScript in the comment section. This script ran in the browsers of those visiting the site, as well as the site owners.

4.     Backdoors

If you’ve detected hacks on your website, and have painstakingly gotten them removed, you’d understandably be perplexed when the site is hacked again. The thing is, hackers often leave a bit of malicious code hidden in another part of your website that allows them to re-enter and reinfect your site again and again. This is obviously why it’s called a ‘backdoor’.

How the attack works

Backdoors are sneaky little vulnerabilities. Most of the time hackers use other vulnerabilities to try and launch one kind of attack. Once they get access to the website, they immediately put in an infected file in an inconspicuous folder completely different from where the original attack started. The file never links to any URL, whether on your website or off, or calls attention to itself. In fact, one of the only ways to find it is if the admin of the website combs through the site’s file system. This makes it extremely hard to detect, even by malware scanners. However, since the hacker knows exactly where the file is, he or she can access, and execute it to override any admin functions.

One specific, yet highly popular backdoor, is the ‘Filesman’. Filesman is feature-rich, so it can do a variety of things, including giving complete access to everything on your site.

With a vulnerability like the Backdoor, it’s important to keep deleting plugins and themes that you’re not using.

It’s easy to ignore the notification on your WordPress admin dashboard that says you have a bunch of plugins to update, but your WordPress site’s security relies heavily on it.

As you can see, finding hacks and getting rid of them can be a ridiculously tedious affair. Most efficient hack-scanning and cleaning systems available require technical assistance. And if you take time-zones into consideration, removal could take about 12 hours or so.

This is why the team behind BlogVault built an automated, one-click hack-detecting and cleaning system, that requires no technical assistance. Click here to check out the free trial!

We hope this list of vulnerabilities and exploits helped you. Let us know what you thought of it in the comments!