16 Dec

No WordPress Security Plugin Prevented Exploitation of Unfixed Arbitrary File Upload Vulnerability in Popular Plugin

When it comes to the chances of vulnerabilities being exploited the reality is that many types of vulnerabilities are highly unlikely to have anyone even try to exploit them. Unfortunately far too often we see security companies and the press making a big deal of vulnerabilities that are are of little to no threat, while ignoring vulnerabilities and broader security issues that are leading to websites being hacked (that lead us to providing information on likelihood that a vulnerability is to be exploited to the data for our service). When it comes to types that are likely to be exploited, the arbitrary file upload vulnerability, which allows a hacker to upload files of any kind to a website, is probably the one with the most exploit attempts and also then ends up leading to the most websites being hacked. So if a WordPress security plugin is going to protect against any type of vulnerability this seems like this is the one you would most want it to be able protect against.

Back in September we tested out security plugins against this type of vulnerability and the results were not good. Of the 12 plugins tested only 3 provided any protection. The protections 2 of them provide was easily bypassed for this particular vulnerability and the remaining plugin’s protection also meant that Editor level and below users could not upload files either.

With the vulnerability tested then the file to be uploaded was included with the upload request, which provides security plugins a relatively easy way to detect the possibility of a malicious upload occurring as they can see all files being included in the request by checking the $_FILES variable. An arbitrary file upload vulnerability can also involve getting a file from another website, which should make it harder to detect.

Just such a vulnerability was disclosed in the plugin Delete All Comments (which recently had 30,000+ active installs according to wordpress.org) by the security company NinTechNet on Saturday, which they had discovered while cleaning up a website that had been hacked due to it. The vulnerability is just the type of thing that could show the value of a security plugin as the vulnerability has not been fixed, so even if you keep your plugins up to date at all times you are still vulnerable if you are using (WordPress could step in to provide a secured version, but so far they have not). So we decided to test out security plugins to see if they are able to protect against it.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.7, installed the version 2.0 of Delete All Comments, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the following HTML to launch the upload request in the exploit attempts:

<form method="POST" action="http://[path to WordPress]">
<input type="text" name="restorefromfileURL" value="[URL of file to be upload]">
<input type="text" name="restorefromfileNAME" value="test.php">
<input type="submit">
</form>

The 15 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. We added three new plugins in this round of testing: Block Bad Queries (BBQ), Centrora Security, and Total Security. Followers of our blog might recognize two of those, as we previously disclosed a pair security vulnerabilities we found Centrora Security and Total Security (yes security plugins can introduce additional security issues on your website). If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

None of the plugins tested prevented the vulnerability from being exploited.

We were surprised NinjaFirewall (WP Edition) didn’t prevent this since the developer was the one that discovered the vulnerability and they state that:

Alternatively, if your are using NinjaFirewall (WP/WP+ Edition), our WordPress WAF, you are protected against it.

One possible explanation for this discrepancy is that we sent the exploit attempt request to homepage of the website while the hack shown in their post had the request sent to /wp-content/plugins/delete-all-comments/delete-all-comments.php. When we sent the request to that URL instead it was blocked.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Failed to prevent exploitation.

Block Bad Queries (BBQ)

Result: Failed to prevent exploitation.

BulletProof Security

Result: Failed to prevent exploitation.

Centrora Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Failed to prevent exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Total Security

Result: Failed to prevent exploitation.

Wordfence

Result: Failed to prevent exploitation.

Protecting Against Plugin Vulnerabilities

Seeing as the security plugins provided no protection, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you. In this case the vulnerability can exploited when not active if the request is sent directly to plugin’s file.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service. We added this vulnerability on Monday.
  • Sign up for our service. Not only do you get alerted if there is a vulnerability in a currently installed version of a plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins. With our service you get a more limited version of this as you can suggest and vote for plugins to have basic security reviews done by us.
26 Sep

No WordPress Security Plugins Protected Against Recently Disclosed Vulnerability That Exposes WooCommerce Order Data

Recently we started testing to see what protection WordPress security plugins provide against vulnerabilities in other plugins (since plugins vulnerabilities are an actual source of websites being hacked, unlike some other things that these plugins make a big deal or providing protection against). The first vulnerability we tested could be used for serving up malware on a website and the second could give an attacker control over the website. Both of those are types of vulnerabilities that are the kind that are often thought of when discussing the security of websites, for example the very popular Wordfence plugin is advertised as “protecting your website from hacks and malware”. Not every security issue though falls into those categories. As you can guess from the name, an information disclosure vulnerability involves the disclosure of information that isn’t intended to be public and those can be a serious issue. For example, if you run an eCommerce you wouldn’t want your customers’ details to be accessible by the public.

WooCommerce is an popular eCommerce plugin for WordPress, which has over 1+ million active installs according to wordpress.org (we use it on this website). There are numerous plugins that expand on its functionality. The security of those isn’t always good. Among the issue we have found in some of those plugins this year were two arbitrary file upload vulnerabilities and a vulnerability that allowed changing the price of products. Recently David Peltier discovered that the plugin Order / Coupon / Subscription Export Import Plugin for WooCommerce (BASIC) had an information disclosure vulnerability that allowed anyone to get a copy of the orders made through WooCommerce on the website. Including in that is not only the details of the order, but the customer’s details, including address and email adress. That vulnerability has now been fixed.

Based on those vulnerabilities in WooCommerce related plugins, it is clear that plugins on websites that likely contain sensitive data are not receiving the security scrutiny that they should be. So if WordPress security plugins provided protection against information disclosure vulnerabilities that could be of significant value.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the version 1.0.8 of Order / Coupon / Subscription Export Import Plugin for WooCommerce (BASIC), and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in the report on the vulnerability.

The 12 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

None of the plugins tested prevent the vulnerability from being exploited.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Failed to prevent exploitation.

BulletProof Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Failed to prevent exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Wordfence

Result: Failed to prevent exploitation.

Protecting Against Plugin Vulnerabilities

Seeing as the security plugins provided no protection, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service.
  • Sign up for our service. Not only do get alerted if there is a vulnerability in the currently installed plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins.
22 Sep

Only One WordPress Security Plugin Fully Protected Against a Recently Disclosed Arbitrary File Upload Vulnerability

Last week we did our first test to see what protection that WordPress security plugins can provide against the exploitation of the vulnerabilities in plugins. The results for a persistent cross-site scripting (XSS) vulnerability were not good, with only 2 of the 11 plugins tested providing any protection and even the protection in those two was easily bypassed.

Earlier this week we disclosed a set of arbitrary file upload vulnerabilities in four plugins by the same developer. While these vulnerabilities are of the type that are likely to be exploited (you can now know how likely vulnerabilities are to be exploited with our service), after we contacted the developer, they took two weeks to fix one and the other three have yet to be fixed two months later. That shows a couple of the problems with being able to protect against plugin vulnerabilities at this time, one being that vulnerabilities are not fixed in a timely manner and the other being that simply keeping you plugins up to date will not protect you.

An arbitrary file upload vulnerability allows an attacker to upload any type of file to the website. They would usually use that upload .php file that contains PHP code, which provide them further access to the website or allows them to take further malicious actions.

To see how security plugins would protect against this type of vulnerability we will test them out against the arbitrary file upload vulnerability that exists in N-Media Post Front-end Form simply because that was the first one of those plugins that we discovered had a vulnerability, which we found while looking in to the possibility that plugin had a vulnerability elsewhere in its code.

From what we see monitoring hacking attempts it looks as if arbitrary file upload vulnerabilities are the most frequently targeted vulnerability in WordPress plugins and from cleaning up many hacked WordPress websites they also frequently are the cause of websites being hacked. Based on that you would expect that if security plugins could protect against some type of vulnerability this would be one type that they would. It also seems like it should be relatively easy to monitor files that are being uploaded directly to the website, by check the contents $_FILES variable of PHP, increasing the chances they can stop this type of issue in its most basic form.

Continuing something that came up while working on the first test, we first trying exploiting the vulnerability in and then for plugins that we found stop exploitation we look if we can find a way to bypass that protection without looking at the underlying code (black-box testing).

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the latest version of N-Media Post Front-end Form, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in our previous post and uploaded a file with a .php extension that contains PHP code.

The 12 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

Only three of the plugins tested, Anti-Malware Security and Brute-Force Firewall, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited in the original test. But we were able to easily bypass the protection in two of those, Anti-Malware Security and Brute-Force Firewall and Wordfence, without even looking the at the underlying source code of how their protection works (that source code would be available to anyone looking to exploit them). With both plugins simply uploading a file with .jpg extension instead of .php evaded their protection. Since you also specify what the file will be named on the server with this vulnerability, the extension of the uploaded file doesn’t dictate the extension of the file on the server.

It is interesting to note that the only plugin to fully protect against the vulnerability, NinjaFirewall (WP Edition), was one of the least popular of the plugins tested, with only 10,000+ active installs. That is a good reminder that the popularity of security plugins has little bearing on the protection they provide.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Prevented exploitation, but bypass around protection was easily found.

BulletProof Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Prevented exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Wordfence

Result: Prevented exploitation, but bypass around protection was easily found.

Protecting Against Plugin Vulnerabilities

Seeing as most of those security plugins provided no protection and all but one other was easily bypassed, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service.
  • Sign up for our service. Not only do get alerted if there is a vulnerability in the currently installed plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins.
14 Sep

Web factory Ltd’s Sleazy Promotion of Their Security Ninja Plugin

One of things we think is important to understand about why security is in such bad shape these days is due to the poor state of security companies. If you were to comes up with a list of phrases to describe bad companies most security companies would match at least one of those. An example of a security company decidedly acting badly we came across recently is Web factory Ltd. They have website named WP Loop and we recently received a visit to our website from a page on their website entitled “Hacked, dangerous & vulnerable WordPress plugins”.

The page starts by stating:

With over 47 thousand plugins in the official WordPress repository and thousands more available on various other marketplaces and sites, finding those that work well is a daunting task. Finding those that are secure and won’t endanger your site is an even harder task due to the complex nature of WordPress security and often massive plugins with thousands of lines of code.

That is true, hence the value of our service. The next paragraph starts:

Although we can’t help you avoid every single bad plugin, we can pinpoint those who have known, confirmed vulnerabilities and security issues.

They then go on to provide a list of vulnerabilities that have been in WordPress plugins that you are supposed to check the plugins you use against:

How to use this page and the list of vulnerable plugins?

If you’re using any of the listed plugins, double-check the version number and confirm that it’s the one with known problems. If so – remove the plugin immediately! This includes deactivating it and deleting. Not just deactivating. You can also contact the author and ask him if the problems have been fixed and if not urge him to do so.

That seems really inefficient way to check for vulnerable plugins when there are a number of tools that can do that for you. Then as we started looking over the list what became almost instantly clear is that list consist almost, if not entirely, of data that comes from the free data in Plugin Vulnerabilities plugin. The vulnerable version numbers listed really give it away, since we are the only data source that provides those. So instead of wading through their list you could have just installed the plugin and it would do the same checking for you (when you sign up for the service among other things, you get access to data on more vulnerabilities than just the ones we are seeing hacking attempts against already):

plugin-vulnerabilites-screenshot

It seemed odd that they clearly knew about our plugin, as the listing comes directly from it, but didn’t tell people just to install it. So why not? Well once you get past the list you get to them promoting their plugin:

Have your WordPress site been hacked?

Don’t despair; it happens to the best of us. It’s tough to give generic advice without having a look at your site, but if you can still login into your WP admin, we suggest installing the free Security Ninja plugin. It’ll perform +40 tests on your site, and with the Core add-on, you can validate the integrity of your core files by comparing them to the secure, master copies stored on WordPress.org. It’s an invaluable tool for any WordPress site!

Worth noting is the fact that they don’t mention that they are in fact the developers of the plugin, which seems relevant when promoting a product. (The plugin also isn’t entirely free, as portion are paid add-ons)

They do gives us a bit of credit on the page, but only as the last listed source, despite most, if not the whole list, being simply taking directly from our plugin:

Sources

The list of latest dangerous and vulnerable WordPress plugins is compiled from various sources including:

Notably they link to our website and not the plugin’s page, which would allow people to see there is a better option for doing the checking and maybe they would also figure out where the data actually came from.

The Opposite of Impossible

They also have a companion blog post that advertises that page, which makes this ridiculous claim:

You can help your WordPress website a lot by installing a free Security Ninja plugin, but you still have to be aware of the plugins you’re using. Until now, it might have been impossible for a regular user to know how to find a bad plugin, but that’s where we step in to help you.

Again they are using our plugin’s data, so they knew that it was possible to do before.

More Misleading Promotion

It turns out this isn’t the end of the misleading promotion of their plugin. On the plugin’s page on the Plugin Directory they have the following section on the Description page:

What others say about the plugin

You can see that they are citing the WP Loop as an “other” despite it being them, the link to “Web smush” redirects to the same page as the WP Loop link.

Security Ninja Doesn’t Prevent a Zero-Day Exploit Attack

On that page they also make a number of bold claims with no supporting evidence to back them up. One that stands out is the claim that the plugin will “prevent 0-day exploit attacks”. A zero-day exploit is an exploit that is being exploited before the developer is aware of it. To be able to prevent those you would need to be able prevent any sort of exploit from succeeding, which is highly unlikely to be possible.

But we did quick check to see if it might prevent one instance that type of thing by we testing to see if the plugin could protect against the same persistent cross-site scripting (XSS) vulnerability we had tested a number of other security plugins against earlier this week. The vulnerability could have been a zero-day, as a hacker appears to have been looking for usage of the plugin when the vulnerability was in the plugin and it looks the type of vulnerability that hackers would target. Of the 11 security plugins we tested it against originally, only two provided any protection, and for those two we easily found a way to bypass the protection. The result for Security Ninja is that it did not prevent exploitation of the vulnerability.