Remote/Local File Inclusions are common attacks on WordPress sites. However, it is Arbitrary Code Execution, that actually does the real damage to your site. Inclusion attacks are generally used in tandem with Code Execution, and learning how they work is key to preventing them.
We’ve been in the WordPress site recovery business for a while now. Over the years, we’ve had a number of our customers come to us with questions about their websites when they noticed something weird, or in the most severe cases, when they lost admin access. We’d try to help out, and most of the time, discover that their site was hacked.
One of the most lethal ways WordPress sites get hacked, in our observation, has been via file inclusion and code execution.
We’ve covered the same attacks and their most well-known approached in a previous piece about the most common attacks on WordPress sites, but with this piece, we hope to help you understand it in a little more detail.
To understand how these attacks work, one of the first things you must be aware of, is they involve PHP code. This is because PHP is a language that servers run on, and it’s also what WordPress is built on. PHP files aren’t just files; they’re executable code. This means that if you have a PHP file and you just access it on your WordPress site, it runs the code it contains.
This is why File Inclusion and Code Execution attacks go hand-in-hand. Once an attacker gets an infected PHP file to your website’s server and runs it, they could use it to do anything with your website.
WordPress plugins allow for File Inclusions in order to ‘include’ (or refer to) files on, or outside of the website’s server.
- Any file that is included from outside your website’s server is said to be ‘remote’. This means even you, as the website admin, access your website remotely… since you’re not accessing it from within the server.
- Any file that’s included from within your website’s server itself (like the files in your website’s database, or files like wp-config.) is known as a ‘local’ file.
The problem arises when plugins that allow website admins and users to access files (remotely, or locally) exhibit loopholes. These loopholes are exploited by hackers to include malicious files, that can be used to hijack the website’s server. However, simply including a static file (one that doesn’t execute code, e.g. a JPEG file) doesn’t cause damage. This is why most File Inclusion attacks involve PHP files.
Although both Remote and Local File Inclusion attacks have technical differences, both of them are used to perform Arbitrary Code Execution. This is what allows hackers to run their bad code on your server, and take control of it.
So in short, this is how these attack works:
- Access: First an attacker would need to get a vulnerable site to ‘include’ a malicious PHP file. This could be done directly (which would need access to your site’s server), or via a WordPress plugin that allows users to ‘include’ files from other locations. Obviously this is a very dangerous situation, especially for any website that allows files to be included without first validating the kind of files accepted.
- Execution: Once file is uploaded, the attacker could just access the file to execute it.
Remote File Inclusion
Websites that allow for Remote File Inclusion usually have a way to check where the file came from. Most of the time, they have a whitelist of websites; only files from these URLs are allowed, and others aren’t.
Here is the general process of an Remote File Inclusion attack:
One of the most famous examples of a Remote File Inclusion exploit combined with Arbitrary Code Execution, was that of a WordPress plugin called TimThumb. TimThumb was used to edit pictures on the fly, without having to open an image editor. Understandably, a lot of websites used it in implementing thumbnail-size images for their users’ avatars. TimThumb’s whitelist consisted of a number of image-hosting websites (like flickr.com and imgur.com). However, the vulnerability in the plugin was that it didn’t verify if the file URLs actually came from those locations: It only checked the words in the URL (or strings) to see if the images looked like they came from a whitelisted site.
Here’s how the TimThumb exploit took place:
Once the attacker executed the malicious file on the server, the damage caused depended on what the file was created to do. Since TimThumb was such a widely used plugin, millions of sites were affected.
Local File Inclusion
Local File Inclusion is a little more complex than Remote File Inclusion, because an attacker has to first create an executable, malicious file on the website’s server environment. This is mostly done by exploiting another vulnerability on the website (say one that allows SQL Injection), by which the hacker can access the website’s server. Once the hacker accesses the server, they can do anything, even override controls to make sure that a malicious file can be created on the server, or uploaded to it. The file can then be executed by just accessing it.
Recently, this vulnerability was observed on the Easy Forms for MailChimp WordPress plugin (v 188.8.131.52). The plugin allowed unlimited forms to be added to WordPress sites, of many different formats. However, the its vulnerability allowed an attacker to upload a PHP file using these forms. Once this was done, the file would get stored locally on the website. The attacker could then execute the arbitrary code.
Arbitrary Code Execution
A hacker’s aim in both File Inclusion attacks, is to execute arbitrary code on the website’s server.
Arbitrary Code Execution though, doesn’t have to only start with File Inclusion including files… in fact a lot of attacks (like Injection attacks) could be used in conjunction with running code arbitrarily.
One way that Arbitrary Code Execution was exhibited, was via WordPress plugins that cache dynamic content, like WP Super Cache. Plugins like these help reduce WordPress sites’ load times for visitors. One of the ways this is achieved, is by using special tags to tell the difference between static content (content on the site that doesn’t change), from dynamic content (that is executed server-side, and is interactive).
Here is how the attack worked:
While this is only one way hackers were able to execute code arbitrarily on the website’s server, there are a variety of ways to achieve the same result. The reason hacks have become more complex, is because hackers keep modifying how they way they exploit vulnerabilities.
There are a few ways to secure your site though. One way is to modify your WordPress site’s .htaccess files to prevent uploaded PHP files from being executed, and to update your themes and plugins. Another way is and to employ good security measures, like a WordPress firewall, or an intelligent antivirus.