16 Oct

More of the WordPress Support Forum’s Terrible Moderation

Earlier today in a post providing the details of a vulnerability that has been fixed in the plugin Starbox, which is currently removed from the Plugin Directory, we noted there was confusion over the removal of the plugin.  In a thread about the issue, “Why was StarBox removed from the WordPress repository?“, a member of the Plugin Directory team had responded to a question about why the plugin was removed with the following:

Yes, I do. It’s not a serious concern. Relax. 🙂

The questioner then responded:

I’m glad it’s not a security reason and so now I can re-enable the plugin.

The answer given didn’t say it wasn’t a security issue and there is one. While it isn’t something likely to be exploited on the average website, as discussed in the details post, for some websites it could be considered a serious concern.

We then left a reply on the thread to see if the terrible moderation of the Support Forum that we discussed last week would strike when simply clearing up that confusion. Here is what we wrote:

He didn’t say it wasn’t a security issue, just that it was “not a serious concern”.

What is probably more accurate to say based on what has been fixed in it since the plugin was removed, is that it is a not a serious concern for the average website, but for high profile websites it could be of more concern.

Our comment was promptly deleted.

As we mentioned in the previous post, that type of deletion isn’t supposed to be happening. Here is the stock answer provided for moderators to respond with if they are asked to edit or delete something:

Generally speaking, posts are only edited or removed where to do otherwise might lead to serious consequences. Previous examples have included posts that accidentally incorporated proprietary code or where the poster asking has reason to fear for their online safety. Having a posted site url come up in Google in NOT a serious consequence. In each case, use your best judgement or ask for a second opinion. If the final decision to to leave the post “as is”, use something like:

When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

We could ask how our reply could be a security concern (or any of the other issues listed there), but it seems the better issue to raise if there is so much concern about the security of the plugin that they would delete someone just correcting confusion over the issue, how can WordPress allow 10,000+ websites to remain vulnerable as they are currently are doing.

Not only did they delete our comment, but they also closed the topic:

Considering the plugin still hasn’t been restored to the Plugin Directory, this is still an open issue. The closing of thread also seems problematic considering what was the last reply before ours, which was also deleted. As can be seen in the copy of the thread from before we posted, previously the final reply on the thread was a question:

So, what’s happening? Is it going to be back or what?

What possibly could be the legitimate purpose of removing that?

If you were going to delete anything from that thread it seems what would be appropriate would the comment from the member of the Plugin Directory (who is also a moderator on the forum and the “WordPress.org Admin”) claiming this was “not a serious concern” and to “relax”. Based on the actions taken in thread that would seem to something people on the WordPress side of things don’t agree with, otherwise they wouldn’t be deleting replies and closing the topic.

Not only does this terrible moderation leave the public not knowing the true status of this particular plugin, but as long it continues it is going to mean that we are not going to return to notifying the Plugin Directory of publicly disclosed vulnerabilities in the current version of plugins, which has already meant that vulnerable plugins with 100,000s of active are still in the Plugin Directory. If even knowing that a plugin has a security risk is cause for deleting multiple thread replies, that seems to indicate that all of those vulnerable plugin installs would be a much bigger issue, but it is one that WordPress is unwilling to properly address either by fixing the forum moderation or by doing the work we have previously taken care of because of their unwillingness to make sure they did not include plugins known to be insecure.

13 Oct

The Moderation of the WordPress Support Forum is Still Terrible

Back in June we suspended notifying the WordPress Plugin Directory of publicly disclosed vulnerabilities in the current versions of plugins until WordPress put forward concrete plans to fix two of the many issues that there currently are with their handling of security related issues. That has meant there are currently plugins with 100,000s of active installs that are currently in the Plugin Directory that have disclosed in the most recent versions, as no one else has taken up doing that (no one appears to have been doing that before we had done it either).

One of the issues we said needed a concrete plan on fixing it was the moderation of the Support Forum, as not only has the current poor handling directly gotten in the way of fixing vulnerabilities,  but we have found that it has dissuaded those knowledgeable on security from participating. That leads to inaccurate security information going uncorrected, for example a couple of days ago someone posted threads for two plugins titled “WARNING: Exploit found in this plugin!”. For one of them the vulnerability was fixed two years ago. For the other plugin the vulnerability has never existed in that particular plugin, it existed in a precursor plugin (though it turns out that a similar vulnerability exists in that newer plugin, which we have now reported to the developer). We could easily have provided that information but considering how often stuff we have written gets edited or deleted even when people are thanking us for the information (in that case the thank you comment was also deleted), it isn’t something we would normally do anymore, which is a loss for the WordPress community.

That editing and deletion isn’t supposed to be happening, here is the stock answer provided for moderators to respond with if they are asked to edit or delete something:

Generally speaking, posts are only edited or removed where to do otherwise might lead to serious consequences. Previous examples have included posts that accidentally incorporated proprietary code or where the poster asking has reason to fear for their online safety. Having a posted site url come up in Google in NOT a serious consequence. In each case, use your best judgement or ask for a second opinion. If the final decision to to leave the post “as is”, use something like:

When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

Clearly thanking someone doesn’t match those supposed reasons and removing useful information that lead to us being thanked is as that says, removing added value.

What was the breaking point for us that lead to us suspending our reporting to the Plugin Directory was a situation where a moderator falsely claimed we had disclosed a vulnerability on the Support Forum and deleted what we had actually said, which would have allowed others to see that their claim wasn’t true, shortly after we had left the reply. But in those previously mentioned threads about an exploit someone really was disclosing vulnerabilities and their comments are still up.

The other day we did respond to something because it directly referred to us and it was the promptly deleted as well. In a thread related to Postman SMTP and why it was removed, which seems to be because of a vulnerability we discovered and disclosed, we were referred to and it contained quite a bit of inaccurate information.

What we found particularly troubling concerning us was this:

If I am feeling indignant, it is because that if the author was apparently able to be reached, as claimed by one of the respondents in the post written by the people who demonstrated the “proof of concept”, then why did the authors of the post not manage to do the same, and then follow the correct procedures by working with WordPress Core and the Author to release a patch before announcing it in public and disseminating widespread alarm.

We disclosed the vulnerability in June and there was not “widespread alarm” at the time. If anyone is causing that type of alarm with this type of vulnerability it would be better to look at another company mentioned in the thread, Wordfence, which just a couple of months incorrectly claimed that another vulnerability of the same type “will be exploited by attackers”.

We had in fact tried to contact the developer and were not able to get in touch with them, even after people were able to get in touch with them it hasn’t lead to the vulnerability being fixed (which isn’t uprising as the plugin doesn’t appear to have been maintained for some time).

We also explained in our reply why we had suspended working with the Plugin Directory team and what that has meant for the security of WordPress. That seems like important information, but the moderators of the WordPress Support Forum don’t appear to have  wanted you to be able to see that.

Our reply didn’t have anything that could be classified as representing “a valid legal, security, or safety concern”, unless a security concern is knowing that WordPress is not handling security well.

What seems more problematic with that, is that the comment directly before ours in that thread, which simply said something along the lines of “hear, hear”, was also removed. That clearly isn’t a violation of the criteria they lay out for why something should be removed.

Another issue in this thread was that there was a claim that Wordfence had answered why the Postman SMTP plugin was removed from the Plugin Directory, when in fact they just speculating like everyone else. The other item we said needs a concrete plan for fixing before we started notifying the Plugin Directory again is in fact making it so that people would actually know why plugins are removed.

We don’t what is more troubling here, that a moderator upon seeing that the poor moderation if leading to websites being less secure thinks the correct response is to continue with the poor moderation or that the moderators appear to be delete all sorts of stuff (like the other comments that got deleted beside in two of those instances) while claiming they are very circumspect in what they would delete.

13 Oct

firstisteguide.com’s “Hacked, dangerous & vulnerable WordPress plugins” Page Incompletely Copies Our Plugin’s Free Data

Back in September of last year we came across a page on the website WP Loop listing vulnerabilities in WordPress plugins. Upon our taking a look to see if it might contain data from any sources we had yet to become aware of, we noticed that the data was largely, if not entirely simply copied from the free data that is included in the companion plugin for our service. They later started adding more data not from our plugin’s data, but because others don’t do the same work we do to determine what versions of plugins are vulnerable it was also inaccurate data.

More recently we noticed a fair amount of traffic coming to our website from the website firstisteguide.com. The page the traffic was coming from appeared to be same page as had been on WP Loop before, “Hacked, dangerous & vulnerable WordPress plugins”, but it contained no listing of vulnerabilities (if you visit wploop.com it now redirects to https://firstsiteguide.com/learn-wordpress/).

More recently they re-added a list of vulnerabilities and it is clearly just copied from our plugin. They in no way note that and in fact make it appear that they are compiling the information from multiple sources. At the bottom of the page is the following:


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

Notably we are linked to last and what is linked to there is not our plugin, but our website, though the data clearly is coming directly from the plugin.

As of two days ago there were entries for 204 plugins on the page and there were 207 in our plugin. All 204 entries on their page were also included in our plugin’s data. Of the three others that were not on their page, two of the plugins, Brandfolder and mb.miniAudioPlayer, were just added to our plugin’s data on Monday and they then appeared in their list yesterday. That all couldn’t be a coincidence.

There are a number of issues with what they are doing, beyond not properly crediting us.

First it would be much easier for people to install our plugin and check to see if they are using listed plugins that currently or previously contained a vulnerability. Since the plugin does the checking for you, while you would need to search over the list to see if a plugin you are using is or was vulnerable.

If you are checking over their list you could easily miss that a plugin you are using is listed. That is in part due to the fact that while they claim to be listing the plugins name they are not. Take for example mb.miniAudioPlayer, which is listed on their page by the name Wp Miniaudioplayer instead. That isn’t because the plugin has multiple names it is referred to, as does happen fairly often, but because the people behind this list are faking providing the name. What they are doing is taking the slug of a plugin, in the case of this plugin, wp-miniaudioplayer, replacing the hyphens with spaces and the capitalizing each word, which isn’t always even similar to the name the plugin goes by.

There is another very serious problem with their listings, they only list the fist vulnerability included in our data for a plugin. That can be seen with the plugin Display Widgets, which if you followed the recent coverage you would probably remember that the plugin had multiple versions that contain intentionally malicious code. In the firstsiteguide.com’s data though it is only listed as having a “remote code execution” in version 2.6. The reason for that is that we have two listing for that plugin, because there was a different issue in that version than the others:

$plugin_vulnerabilities["display-widgets"] = array(
	"1" => array(
		"FirstVersion" => "2.6",
		"LastVersion" => "2.6",
		"TypeOfVulnerability" => "remote code execution",
		"URL" => "https://stallion-theme.co.uk/display-widgets-plugin-review/"
	"2" => array(
		"FirstVersion" => "2.6.1",
		"LastVersion" => " ",
		"TypeOfVulnerability" => "spam post creation",
		"URL" => "https://wordpress.org/support/topic/display-widgets-plugin-v2-6-3-1-includes-hacking-code/"

That also makes it quite clear where their data really comes from, because other data sources didn’t list things that way.

Back when we first noticed what had happened when the website was WP Loop we noticed there was companion blog post that made this obviously false claim:

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.

We also left a comment at the time noting that they were saying something they knew was false there and also mentioning that list came from our data. If we are recalling things correctly they responded and said it would be noted where the data was really coming, from, though there is no longer any comment like that on the post.

09 Oct

Google Not Always Providing Really Relevant Results When Searching For WordPress Plugin Vulnerabilities

In looking at recent traffic from Google coming to our website by way of the Search Analytics portion of Google’s Search Console we noticed that for three of the top five sources of clicks to our website relate to something we don’t have any really relevant content for. The queries all relate to the plugin Contact Form 7:

  • contact form 7 vulnerability
  • contact-form-7 exploit
  • contact form 7 exploit

We don’t have any posts that relate to vulnerabilities in that plugin, the closest that we come to that are some posts about vulnerabilities in software that works with it, which have “Contact Form 7” in their name. In looking at the results for the above queries, the pages from our website do it fact relate to one of those plugins:

While it might be somewhat relevant to show results from plugins that work with Contact Form 7 if there were not disclosed vulnerabilities or exploits for Contact Form 7, it seems unlikely that those pages related to Contact Form 7 Database would be relevant for many people doing the searches considering that according to wordpress.org there are 5+ million active installs of Contact Form 7 and only 7,000+ active installs for Contact Form 7 Database.

One of the problems with these types of results is that people do not appear to always be looking closely at the results before taking some further action. A month ago someone posted on the support forum for Contact Forum 7 claiming they found an “article from about 7 weeks ago talking about SQL injection in Contact Form 7”. They went to on to ask

And is there an update coming out to fix it? Hopefully you can identify what needs to be fixed.

What they were referring to was a post we put out with the details of a fixed vulnerability in another related plugin, Save Contact Form 7. That plugin is also is much less popular than Contact Form 7, which only 10,000+ active installs.

Considering the popularity of Contact Form 7 and that there haven’t been any recent disclosures of vulnerabilities in it, the chances that a security review would find any issues in the plugin are low, but if you are looking for an assessment of the security of the plugin you can order a security review of it (or any other WordPress plugin for that matter) from us. That currently includes checking for the following issues:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with import/export functionality
  • Security issues with usage of is_admin()
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites
06 Oct

Wordfence Doesn’t Want You to Know We Discovered the Vulnerability in Postman SMTP

We have seen a lot sleazy stuff out of the WordPress focused security company Wordfence, including claiming that they care more about security than the WordPress team as justification for creating a fake threat, so it shouldn’t be surprising to find their post about the removal of the plugin Postman SMTP from the Plugin Directory, which people assume is due to a reflected cross-site scripting (XSS) vulnerability we discovered, doesn’t mention us or link to our post despite being about the only substantive thing mentioned in their post. They clearly are aware of who the source was as the second paragraph clearly references our post:

On June 29, an unnamed security researcher published the details of the vulnerability, including a proof of concept. A proof of concept is a demonstration that shows the plugin author (and in this case the entire internet, including potential attackers) how to exploit the security vulnerability. The security researcher had apparently attempted to reach the author but had been unable to.

It is worth noting that here that this type of vulnerability is highly unlikely to be exploited on the average website (contrary to a recent claim by Wordfence that this type of  vulnerability “will be exploited by attackers“) and the proof of concept included just reiterates what is already mentioned in detailing the vulnerability, so someone that would be exploiting this type of vulnerability shouldn’t have a problem without it. Someone looking to do a targeted attack against a website using this plugin, likely could have easily found this vulnerability on their own (and who knows, they might already have).

One of the reasons we include a proof of concept on how to exploit vulnerabilities is so that others can double check our work, as among other things we often find that vulnerabilities that are being disclosed and claimed to be fixed, haven’t actually been. If there is a proof of concept it is easier to catch that vulnerability hasn’t been fixed and then we can work with the developer to get it fixed (and usually in that situation it can be fixed very fast). It also helps to check if there are other related vulnerabilities that have been missed, as has been the case with Wordfence’s discovered vulnerabilities in the past (or more recently them missing that vulnerable code still was in a plugin, though not accessible). There also was the situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it.

It is also important to note that all major web browsers other than Firefox have XSS filtering to protect against this type of vulnerability for years, which is likely plays an important role in it not being likely to be exploited.

When we have discussed things that Wordfence has written we have properly credited them.

Advertising Over Improving Security

We wouldn’t mind them not mentioning us if they had finally decided to actually help the effort to get WordPress to properly handle removed plugins, since that is so important. Instead their post is mostly just an ad for their plugin and service, which both leave people not knowing why plugins are removed.

Wordfence clearly understands there is an issue with people not knowing why plugins are removed as the first paragraph of their posts states:

We have received a number of questions regarding the Postman SMTP plugin which was removed from the WordPress.org directory this week.

We assume it was removed because it contains a publicly known reflected cross-site scripting (XSS) vulnerability that has not been fixed.

And later they write:

Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

They didn’t write anything about doing anything to resolve that situation, which is easily resolvable if WordPress wanted to take action, but here is all the advertising they had time to include in the post instead:

Both Wordfence Free and Premium users who have the firewall enabled have been protected against attempts to exploit this vulnerability from day one. In addition, we alerted all Wordfence users who have the plugin installed when it was removed from the plugin directory.

It should be noted they didn’t provide any evidence that their plugin actually can protect against this type of vulnerability (or for that matter do they provide evidence that it does for other types and our testing hasn’t shown it to provide much protection). As we mentioned before the major web browsers other than Firefox provide protection against this type of vulnerability as well, something Wordfence didn’t note.

Wordfence Firewall Includes Robust XSS Protection

The Wordfence firewall includes protection against new and emerging XSS attacks. Both Wordfence free and Premium users have been protected against this attack since (and before) it was made public. This is a great example of why using a firewall to protect your website is so important: you are immediately protected against most new threats.

In cases where we don’t already protect against a new threat, we develop a new firewall rule, deploying it to our Premium customers in real-time and free customers 30 days later. This ‘virtual patching’ by our security analysts and developers keeps your sites safe.

Wordfence Alerts You When Plugins Are Removed From WordPress.org

When plugins you have installed on your site are removed from WordPress.org, Wordfence alerts you. There is a long list of reasons why the plugin team at WordPress.org might remove a plugin from the directory. One common reason is that someone has discovered a security vulnerability that has not yet been fixed. Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.


If you haven’t already, we suggest that you install Wordfence on all of your WordPress websites. It will alert you when your plugins have been abandoned or removed from the the WordPress directory. Its firewall will also protect you against new and emerging attacks.

Finally, consider upgrading to Wordfence Premium if you haven’t already. The real-time firewall rule updates will protect you from the latest threats. In addition, the real-time IP blacklist will stop all attacks from the most malicious IPs, regardless of what they’re up to.

Our Advertising

Since Wordfence is going to use a vulnerability we discovered to advertise their service so garishly, we will quickly plug our service, which would have not only warned you about the vulnerability in you were using the plugin back when it was disclosed in June, but we would have also have been available to help you make the best decision as to deal with.

The more customers we have the more we are able to improve the security of WordPress plugins for everyone using them. While this vulnerability has gone unfixed, this week we help get vulnerabilities fixed in plugins with 140,200+ active installs and we have contacted developers of plugins with another 500,000+ active installs about vulnerabilities in them that need to be fixed.

Fixing the Vulnerability

As we said before the vulnerability isn’t something that is a big concern, so it wouldn’t be a big risk to keep using the plugin in its current form, but fixing the vulnerability is easy.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php in the plugin replace this line:

value="<?php echo $_REQUEST['page'] ?>" />


value="<?php echo esc_attr($_REQUEST['page']) ?>" />

The esc_attr() added will escaping the value, which prevents the possibility of reflected cross-site scripting (XSS).

04 Oct

Ninja Forms Could Have Avoided Recommending and Using a Vulnerable Plugin If They Used Our Service

Back in June we disclosed a minor vulnerability in the plugin Postman SMTP that we had discovered. We were not able to contact the developer of the plugin and it hasn’t gotten fixed since we disclosed it. In the past we would have notified the Plugin Directory of the issue and the plugin would have been removed, but due to WordPress’ continued poor handling of security related matters we have suspended reporting publicly disclosed vulnerabilities in the current version of plugins until they take concrete steps to start notifying people when they are using removed plugins and improve their forum moderation (which causes problems for people trying to get vulnerabilities fixed).

Whether due to this vulnerability or something else the plugin was removed from the Plugin Directory yesterday. In looking to see if there was any information that indicated there might be some other issue with the plugin we noticed this recent tweet:

So the makers of a very popular contact, Ninja Forms, which has 900,000+ active installs, were recommending using a plugin with a known security vulnerability. It seemed possible that this wasn’t a new recommendation, just a new tweet for something they had written some time ago. But in looking at the linked post, it turned it was from September 27. It also turned out they were not just recommending the plugin, but also using it:

Postman SMTP is one of the two services that we recommend highly and use internally (the other being Mailgun). We’ll spend the next few minutes introducing them to you and covering the (very easy) setup process. Let’s look at making email easy again! 🙂

If Ninja Forms had been using our service they would have been notified back in June that they were using a plugin with a known vulnerability. We then could have helped them work out how best to handle the situation, including providing them a fix until the developer resolved the issue in a new version or they moved to another plugin. They then also could have avoided recommending something with a known vulnerability.

For those aware that there are other data sources available through plugins/services and thinking Ninja Form could have used them, think again. We just checked and found that the WPScan Vulnerability Database and ThreatPress, both of which we mentioned recently, don’t have the vulnerability in their data sets, even though it was publicly disclosed over three months ago.

The Ninja Form post also makes a claim that seems inaccurate, as one of the “three big reasons” given to use it is:

Actively supported

The plugin had not been updated in two years as of its removal yesterday and was only listed as being compatible with up to WordPress 4.4.

For those using a plugin that has been abandoned that they want to keep securely using them, we now offer a service for taking over and maintaining them, which includes us doing a security review like the ones we do for plugins suggested/voted for by the customers of our service.

03 Oct

Wordfence Still Being Irresponsible When It Comes To Disclosing Vulnerabilities

On September 22, we discussed a PHP object injection vulnerability that had been fixed in the plugin Appointments, which we had spotted being fixed due to the proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. What was somewhat concerning about the handling of the vulnerability was that the vulnerable code still was in the plugin, though not accessible through it anymore. What had happened is the code originally was contained in one file and then that file’s contents were split among several files, but the old file was never removed. After we notified the developer, that file was removed, but the version number wasn’t changed so those already running 2.2.2 still have the code.

Two companies with a security focus had missed the code was still in the plugin, the developer of the plugin, WPMU DEV, and the discoverer of the vulnerability, Wordfence. That is a good reminder of why providing the details of vulnerabilities that has been fixed is important because even security companies can miss issues related to a vulnerability. That has been the case in multiple instances with the few vulnerabilities that Wordfence has disclosed in the past, including a situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it. Making those instances more problematic was that Wordfence failed to provide the details that would have easily allowed someone else to check to make sure everything had been properly resolved. Only because we did the work to figure details of those vulnerabilities were we able to spot and help get some additional related vulnerabilities fixed in some of the plugins.

In the post on that vulnerability in Appointments we wondered if Wordfence would handle the situation better, if and when they mentioned that vulnerability:

 If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

We now have the answer, they didn’t. They release a post on it and couple of apparent PHP object injection vulnerabilities yesterday and it lacks the details that would have allowed someone to easily see that the same code existed elsewhere in the plugin. Since a PHP object injection vulnerability requires more than just knowing about the vulnerability (you need to be aware of code that can be accessed through the vulnerability), providing more details wouldn’t likely to have done little to increase the risk from disclosing more details.

Considering they are claiming all three vulnerabilities are zero-day vulnerabilities, which are vulnerabilities being exploited before the developer becomes aware of them, some hackers would already be aware of how to exploit them, further reducing the additional risk caused by doing that.

In that past Wordfence has referred to any vulnerability they discovered as a zero-day vulnerability and the post lacks details that would make it clear these all were really zero-day vulnerabilities, so the claim of them all being zero-days seem a bit questionable (though PHP object injection vulnerability are highly likely to be exploited).

The Missing Details Could Be Useful

For one of the other vulnerabilities, in the plugin Flickr Gallery, we also spotted it being fixed through our proactive monitoring. What isn’t mentioned in Wordfence’s post or further discussion of that post is a note added to that plugin alongside the fix for the vulnerability:

This plugin is deprecated, please remove it from your WordPress install.

With the third plugin we didn’t notice a PHP object injection being fixed in it at the time and in looking at the changes so far we haven’t figured out where there would have been a PHP object injection fixed. That vulnerability is supposed to have been fixed in version of the plugin RegistrationMagic-Custom Registration Forms.

In looking over the changes made in that version the only change that directly involves code that could be involved in PHP object injection looks like this in version (in the file /includes/class_rm_dbmanager.php):

$result = maybe_unserialize($wpdb-&gt;get_var("Select form_options FROM `$table_name` where `$primary_key` = $form_id"));

In the code has been changed to use a prepared statement in the SQL query in it:

$result = maybe_unserialize($wpdb-&gt;get_var($wpdb-&gt;prepare("Select form_options FROM `$table_name` where `$primary_key` = %d",$form_id)));

There isn’t an obvious way that would prevent a PHP object injection vulnerability.

The rest of the changes mainly involve using prepared statements for SQL queries and adding a missing function.

As of version there look to be 61 usage of the maybe_unserialize(), so it could be the change made in that version impacts code elsewhere that would have lead to PHP object injection. We are going to have to look closer at the rest of the code to try to figure out what is going on. If you have figured it out, please let us know.

Knowing where a PHP object injection would have been fixed there is important because it could help to get other vulnerabilities fixed, since it would make it more likely that others could spot similar vulnerabilities. For example, the way we noticed the other two vulnerabilities being fixed also led to us identifying 9 unfixed vulnerabilities related to PHP object injection that we disclosed just last month (we noticed additional ones through other methods):

29 Sep

Detectify Doesn’t Do A Good Job of Protecting WordPress Websites

When it comes to security these days you have situation that should be a crisis for the industry, 10s of billions on their products and services and yet a quick perusal of the news would show that the results for all the money spent are not good. Instead as far as we have seen the security industry has no problem with the current situation and if you point out some of the problems leading to that you are likely to be criticized.

As an example of how the money is being spent on solutions that are not doing job, let’s take a look at company that we ran across recently, Detectify. That is marketed as the “Leading Web Security Scanner for Continuous Security”, though looking at what it provides for WordPress websites indicates that if iit’s the leading scanner, then the lead isn’t very impressive.

It is claimed to test for “700+ vulnerabilities”, which would seem to leave a lot of vulnerabilities missing considering that we have a lot more vulnerabilities in our data set from just vulnerabilities in WordPress plugins and that service isn’t limited to just WordPress websites.

Here is how the service is described as working, which as we will get to, seems both inefficient and a security risk when it comes to WordPress websites:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do. We provide you with descriptive reports of the results so that you can continue to build safe products.

Limited Tests of Plugin Vulnerabilities

Twice a month Detectify releases a post with new additions to their testing. For the period that is roughly July and August the entries (1, 2, 3, 4) they added tests for five claimed WordPress plugin vulnerabilities:

  • WordPress youtube-embed-plus CSRF
  • WordPress stop-user-enumeration Bypass
  • WordPress dsubscriber SQL Injection
  • WordPress wp-hide-security-enhancer LFI
  • WordPress spiffy-calendar XSS

The quantity of WordPress plugin vulnerabilities they added tests for is incredibly underwhelming. By comparison in July we added 28 vulnerabilities to our data set and in August we added 35 vulnerabilities. What is even more striking is in total they only listed 17 tests added during the two month period, so their limited testing isn’t just a WordPress issue.

When it comes to security, quantity isn’t everything, but the quality of their additions might be worse.

What seems to the most important thing to note is that all of the WordPress plugin vulnerabilities they added checks for had already been fixed before they were disclosed, so simply using our Automatic Plugin Updates plugin to keep your plugins automatically updated would have provided you better protection than their paid service. (If the vulnerabilities hadn’t been fixed their service wouldn’t do anything to help you do deal with them.)

Where that is most relevant is for the only serious vulnerability they added a check for, the arbitrary file viewing vulnerability in WP Hide & Security Enhancer (it is concerning they incorrectly classified that as a local file inclusion (LFI) vulnerability). That vulnerability was fixed back in February, but was only disclosed by the discoverer in July. That vulnerability also shows how we provide superior data on WordPress plugin vulnerabilities over anyone else since we have been warning our customers about the vulnerability since it was fixed in February.

By comparison in both July and August eight of the vulnerabilities we added had yet to be fixed. That included multiple vulnerabilities that are of types that are likely to be exploited.

Among the other issues is that two of the vulnerabilities they listed are not really vulnerabilities. The claimed bypass vulnerability in Stop User Enumeration isn’t really a vulnerability as usernames are not intended to be a secret with WordPress. The claimed SQL injection vulnerability in DSubscribers, is only exploitable by Administrators, which can normally do the equivalent of SQL injection.

That claimed vulnerability in DSubscribers also raises another concern with the Detectify service, which also applies to the cross-site request forgery (CSRF) vulnerability in YouTube. For both of those issues the action taken is done by someone logged in as an Administrator, so if the service is actually is simulating an attack it would require the service to have access to an Administrator account in WordPress. That obviously is a security risk and one that isn’t needed to check these things, since you could just check the version in use.

Are They Finding Additional Vulnerabilities?

For the amount of the money they are charging they are doing a bad job of providing any protection against known vulnerabilities in WordPress plugins, but since they are doing other testing, if the testing was any good it should be able to identify additional vulnerabilities in WordPress plugins since there are plenty to be found. We were not already aware of any recently disclosed vulnerabilities they found and the only indication they might have found any vulnerabilities in WordPress plugins is a post from last week, that mentions several very low level vulnerabilities, reflected cross-site scripting (XSS) vulnerabilities, they may have discovered (it isn’t specified who discovered them in the post, but some of them don’t appear to have been disclosed elsewhere so far).

The details in the post though are very strange. For example, one of the vulnerabilities is supposed to impact versions prior to a certain version, but the next version contains no security related change. It looks like they might be referring to a different version that contained a fix for a different security vulnerability. We did confirm that at least two of the vulnerabilities exist in the current versions of the respective plugins. There is no indication that the developers of those plugin or some of the other listed plugins been notified about them, which would be irresponsible of Detectify not to do. We will probably have more on this once we have had a chance to more fully look over the plugins in question and if we hear back from the developers of the current vulnerable ones (we just notified the developers of the two plugins we have confirmed are currently vulnerable so far), but the information so far doesn’t project that Detectify is a high quality security company.

We Offer Better Protection for a WordPress Websites

As was mentioned earlier if you are looking for information on vulnerabilities in WordPress plugin we are going to provide much better data for less money than Detectify. We also do it in a more secure fashion as we don’t need access to your WordPress installation directly, all you need to do is install the service’s companion plugin, which securely communicates transfers information on what plugins are used to our service and then any vulnerabilities in them is sent back to the website.

On top of just getting better data on vulnerabilities, we actually are here to help you if are using an unfixed vulnerabilities (we also work with developers to get them fixed, so all you and everyone else would need to do is update them to protect yourself). Also as part of our service you have the ability to suggest/vote for plugins to receive a security review from us, which involves checking for reflected cross-site scripting (XSS) vulnerabilities as well as a number of much more serious types of vulnerabilities.

28 Sep

WPCampus Failing to Credit Us and Spreading Inaccurate Information on WordPress Plugin Vulnerabilities

One of the many issues we have noticed when it comes to information on WordPress security you can find on the web is that often the original source of information is not being credited in articles written about issues. We have seen plenty of that happen not just to us, but to many others as well. That credit can be an important reward for doing things like discovering new vulnerabilities, which otherwise have little return. Another issue that comes with that is that we frequently see that the subsequent articles have inaccuracies, sometimes major, which without the possibility of seeing the original are more likely to be repeated subsequently.

As example of where that credit can have an impact, we recently had someone sign up for a free trial of service that originally came to our website from the page Vulnerable WordPress Plugins Report for the Week of September 1, 2017 on the WPCampus website.

In looking over that page we noticed that what was written about us was wasn’t entirely accurate. Here is what was written:

 Also disclosed this week were PHP Object Injectionvulnerabilities in the plugins JayJ Quicktag,VideoWhisper Live Streaming and WP Smart Security (currently unfixed).  All three were discovered by researchers at pluginvulnerabilities.com utilizing the php-grinder.com service. PHP-Grinder is a static analysis tool designed specially to scan WordPress plugins and PHP-based GitHub projects for potential security vulnerabilities.

We are not sure where the claim that all three of the vulnerabilities were found using php-grinder.com. If that post had linked to our posts for the vulnerabilities, people could have seen that we linked to php-grinder.com as a source for the one in WP Smart Security. For the other two we didn’t link to it because it wasn’t a source. That really isn’t a big issue, but as we started looking around we saw larger issues.

(Also worth noting, unlike the writer of the post, we didn’t find the data presented by that website to be of much value.)

Sources Lacking

On the post Vulnerable WordPress Plugins Report for the Week of September 22, 2017 the first paragraph reads as follows:

The critical disclosure this week is an Arbitrary File Upload vulnerability in the plugin All Post Contact Form.  It appears that the plugin doesn’t do any checking on the file type that is being uploaded and saves it to the uploads directory. This means an attacker could upload a backdoor script to your site and then access it in your site’s /wp-content/uploads/ directory.  If you remember back to my Access Denied presentation, this scenario is precisely why I suggest denying access to all file types in the uploads directory except for those you specifically want the public to have access to.  It is highly recommended that you remove this plugin immediately.

From that you wouldn’t have any idea we were the discoverer and discloser of the vulnerability. While there are three links in the paragraph none of them are to our post. That seemed odd to us.

The second paragraph again doesn’t mention us, but it reads a lot like something that was written based off of a post we wrote a week before:

While not in the report this week, I came across a google dorkentry in exploit-db.com that targets the .user.ini file generated by  the WordFence plugin.  The .user.ini file contains a full path listing to the wordfence-waf.php file.  By default, the plugin should include an entry in the site’s .htaccess file to deny access to this file.  In addition, it should warn nginx user’s to include an entry in their configuration file.  However, it doesn’t appear that the plugin verifies an .htaccess file is actually in use, or that the nginx configuration has been made.  IIS users are simply out-of-luck with no warning or instructions on how to deny access to the file.  A quick search shows that there are quite a few sites out there using Wordfence with no protection against disclosing this information.   Now, the disclosure of the full path by itself won’t compromise your site. However, this information can be used in combination with other attacks that require knowing the server path.  Regardless, if you use Wordfence, I would suggest checking your site to see if you can access the .user.ini file.  If so, make sure to add the configuration changes needed in order to block it from public access. If you run into issues figuring out how to do so, reach out to me and I’ll assist.

The post Vulnerable WordPress Plugins/Themes Report for the Week of August 25, 2017 is entirely based on a vulnerability we discovered and disclosed, but once again there is no mention of us or link to our post in their post.

Citing Your Sources

Beyond any common courtesy, seeing as WPCampus is focused on higher education you would expect that what is on their website is in keeping with higher education’s standards when it comes to sourcing.

As an example of that, which popped up at the top of search results when went looking for example of that standard, here is what UC Berkeley says:

Whenever you quote or base your ideas on another person’s work, you must document the source you used. Even when you do not quote directly from another work, if reading that source contributed to the ideas presented in your paper, you must give the authors proper credit.

Citations allow readers to locate and further explore the sources you consulted, show the depth and scope of your research, and give credit to authors for their ideas. Citations provide evidence for your arguments and add credibility to your work by demonstrating that you have sought out and considered a variety of resources. In written academic work, citing sources is standard practice and shows that you are responding to this person, agreeing with that person, and adding something of your own. Think of documenting your sources as providing a trail for your reader to follow to see the research you performed and discover what led you to your original contribution.

That clearly hasn’t happened here.

The WPCampus website prominently links to a code of conduct, which makes no mention of handling sourcing, so maybe they don’t care about it.

More Questionable Sourcing

While the posts are titled reports of vulnerabilities in plugins for a given week, if you actually want to see the vulnerabilities for a week you can have to look at a separate Google Sheets page. Looking at the one for last week we noticed another instance of questionable sourcing. The entries for Welcart e-Commerce and Invite Anyone are sourced to changeset entries, which don’t mention the vulnerabilities in question. It is possible the person behind these post noticed those all by themselves, but since we know they are looking at our blog, it seems plausible that a partial source was our plugin details posts about those vulnerabilities, which we spotted through our proactive monitoring of serious vulnerabilities being included in changes made to plugins (which it turns out can also spot vulnerabilities being fixed). That is a minor issue in comparison to the other issue we noticed in that spreadsheet.

Inaccurate Version(s) Affected

One of the things we tout about our service is that we are the only data source that tells you which version of plugins are vulnerable.  That can be rather important information in certain instances. Let’s say you are dealing with a hacked website with very out of date plugins, which is common. With our data you might be able to see that a vulnerability has existed in some older versions of the plugin, but didn’t exist in the version in use on the website. With other data sources you wouldn’t know that, so you might believe that was the source of the hacking and only later find out it wasn’t when the website has been hacked again.

If you were to look at the spreadsheets from WPCampus you would think that you could get that information from them as well, but it turns the information is not accurate.

Staying with the entries from last week, many of the entries have a range of affected versions like the one for a PHP object injection vulnerability in Invite Anyone, which states that “1.3.18 and earlier”. That vulnerability was introduced in version 0.8, so versions earlier than that didn’t contain it.

It isn’t a situation where the person behind this is simply listing that older versions are vulnerable, as the entry for a reflected cross-site scripting (XSS) vulnerability in 2kb Amazon Affiliates Store list that only version “2.1.0” is affected. When in fact all previous version were affected. We don’t know where the idea that it impacted less versions comes from since the discoverer of the vulnerability lists it as impacting versions “2.1.0 and below“.

26 Sep

Wordfence Falsely Claims Current Version of Removed Plugin Contains Vulnerability That Was Fixed Over Six Years Ago

A couple of weeks ago we noted that Wordfence was trying to make people reliant on their plugin instead of helping everyone in the WordPress community by getting behind the effort for WordPress to start alerting when websites are using plugins that have been removed from the Plugin Directory. One of the reasons we noted as to why what they were doing was problematic even for those using their plugins, is that the people on the WordPress side of things know why plugins are removed and could let people know why, while Wordfence can’t. It turns out though that Wordfence will present things in way that leads to people to believe otherwise, while in the case of at least one plugin, presenting incredibly inaccurate information about the security of it.

Through monitoring of the WordPress Support Forum we do to keep track of vulnerabilities in WordPress plugins, we came across the thread about the plugin Sermon Browser, which has been removed from the Plugin Directory. The original poster in thread wrote:

I just received a “Critical” security notice from my website last week. It stated that the plugin was removed from the WordPress repository because of critical security issue. Apparently a SQL injection vulnerability has been identified.

I am sure the owner was notified of the removal. But I would expect a “sticky” post or an update or something. Has anybody else heard of any response to this?

Below that was the message from Wordfence:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

Following the link to the entry on the WPScan Vulnerability Database in that message brings up this page:

The most important things to note in that is the vulnerability is not labeled as being fixed and the dates, the listing was added on “2014-08-01″ and last updated ” 2015-05-15″. From that page you can get the actual information on the vulnerability.

In looking over things we found that the vulnerability was actually fixed the same day it was disclosed, back on April 26, 2011.

That the information in the WPScan Vulnerability Database isn’t accurate isn’t a surprise. It was just back in June that we discussed their inaccurately label an unfixed vulnerability as being fixed. In April we noted another instance where they labeled fixed plugins as not being fixed. We could go because there are plenty of instances we have discussed on this blog, which certainly are not all of them.

WPScan’s accuracy issues are only part of the problem here, as Wordfence is choosing to further spread the inaccurate information. Either they haven’t done any due diligence at all on their data source on plugin vulnerabilities, which would not put them in a good light, or what seems more likely, they know and don’t care. It’s not like no one has pointed out the problem with Wordfence using that data before, we did that back in May. The other option Wordfence could use is to check the information to make sure it is correct before passing it along to those using their plugin, but what we have seen repeatedly is they either don’t have the skills to do that sort of thing or are too lazy to do that.

If you are a customer of Wordfence’s you might want stop that since you are giving money to a company that doesn’t seem to have interest in really improving security, but you should at least contact them and let them know they should get behind the effort to get WordPress to properly handle alerting for removed plugins.

If you want accurate data on vulnerabilities in WordPress plugins you can get that with our service or in more limited form with the free data on vulnerabilities that are already being exploited that comes with the companion plugin for our service.

If you are using a plugin that isn’t being supported by the developer anymore, over at our main website we offer a service for taking over abandoned WordPress plugins, which includes doing a security review of it.