20 Oct

WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and in every instance we have seen so far, without providing a warning as the low quality of the data. As example here was what Wordfence’s plugin recently sent out to people using the plugin Sermon Browser:

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

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

As we noted previously, the vulnerability being linked there had been fixed six years ago. For whatever reason when it was added to WPScan’s data three years ago it was not listed as being fixed, so when Wordfence reused the data without checking it first they spread inaccurate information. They didn’t include a disclaimer to warn people that they hadn’t checked that data, they even make it sounds like the opposite as they said “It has unpatched security issues”, and therefore didn’t know if it there was any veracity to the claim of a vulnerability in the plugin.

The problem with WPScan’s data isn’t limited fixed vulnerabilities are not correctly labeled as being fixed. Another issue is vulnerabilities that didn’t actually exist being included and labeled as being fixed despite not existing, an example of we just ran across while preparing another post. That could be a problem if you were using WPScan’s data while working on cleaning up a hacked website, since you might believe that you have discovered a likely cause of a hacking, through an outdated plugin, only to later find that wasn’t the case when the website gets hacked again.

This isn’t the first time we have run across this, but what we found notable about this instance is that one of our blog posts is cited despite contradicting their information.

Here is the entry as it is currently:

The claim is that there was an unauthenticated arbitrary file upload vulnerability in the plugin WP Job Manager, which has been fixed. There first reference for that, an entry at Packet Storm from July of last year, makes the claim that there was a remote shell upload/arbitrary file upload vulnerability as of version 1.25. In August of last year we wrote a post detailing why that was false, as the plugin limits what types of files can be uploaded. The plugin did and still does allow anyone to upload files permitted by WordPress.

The third reference cited by WPScan states that:

 Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in.

All that indicates is that those not logged in to WordPress can no longer uploads files through WordPress AJAX functionality, but as we already mentioned the plugin did not allow arbitrary files to be uploaded, so the change does not relate to what they said was fixed.

What is the other important part of this is what was mentioned in the post of ours that was cited:

But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

As the title of our post indicates, “Image Upload Capability in WordPress Plugin Being Abused”, the issue with this plugin was that the ability to upload images was being abused. The change made doesn’t actually remove that capability, it just removes the ability to do that through AJAX. You don’t have to take our word from that, here is what one of the developers said:

Hi there! They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

So to recap, the vulnerability that WPScan lists didn’t exist, but if there was a security vulnerability in the plugin, it still exists, just the way it was being abused at the time was removed.

While we think that WPScan’s data is good source for a lot of people because it can be accessed for free, you do get what you pay for. Where its use is more problematic is when it is used by security companies without a proper disclaimer as to the sourcing and quality issues, which also extend to have a limited set of new vulnerabilities in it. If those companies were to admit to all of that, it would probably make more people understand that the inflated claims these companies often make about their expertise are far from the truth. (It would also help us, as once people realize the value of such data, getting better quality data would likely be of more interest to some of them.)

20 Oct

Just Because a WordPress Plugin is Popular, It Doesn’t Mean It is Secure

Earlier this week we discussed an incorrect belief that WordPress plugins that are monetized will have any discovered security issues quickly fixed, which led to the suggestion that you should only use monetized plugins. That is far from the only time we have seen advice on choosing plugins to use with an emphasis on security that doesn’t hold up to scrutiny. Another one out there is that popular plugins are somehow more secure. The reality is that we haven’t seen any evidence presented that would back up there is a correlation between popularity and security. About the closest we can think of is that it does appear that people looking for vulnerabilities for non-malicious purposes (whether they be security researchers or security companies interested in publicity) are more likely to look at more popular plugins. That seems to be at least partly due to the fact that security journalist are more likely to cover very minor vulnerabilities that have been fixed in popular plugins than unfixed vulnerabilities that are being exploited in less popular plugins, despite the latter being much more important to cover.

That brings us to a very popular plugin we recently took a look into after a vulnerability was vaguely disclosed in it. The plugin Duplicate Page has 300,000+ active installations according to wordpress.org. That plugin allows duplicating pages and posts. Recently the security scanner service Detectify disclosed that the plugin has or had contained an “Authenticated XSS” vulnerability. As we have done with other vulnerabilities they have been vaguely disclosing, but usually not bothering to notify the developer of, we went to try to determine what the issue was and then notify the developer. Once we started looking into this we found five vulnerabilities in the plugin due to multiple security failures, most of which involve failing to do security basics.

In looking at the code we first found the value of the GET or POST input “post” is set to the variable “$post_id ” in the file /duplicatepage.php without being validated or sanitized:

93
$post_id = (isset($_GET['post']) ? $_GET['post'] : $_POST['post']);

Later in the file the value of the variable is output with being escaped:

169
wp_die('Error! Post creation failed, could not find original post: ' . $post_id);

That is a reflected cross-site scripting (XSS) vulnerability and appears to be what Detectify was referring to as it occurs it can be exploited when logged in to WordPress.

A basic rule of security, put a number of different ways, is to not trust user input, but that hasn’t been applied in this plugin based on that.

The value of the variable is also used in the following SQL statement:

143
$post_meta_infos = $wpdb->get_results("SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id=$post_id");

That could lead to SQL injection, which involves additional code running in database query that comes from user input. SQL statements that involve user input should be parametrized to prevent that occurring, which hadn’t been done with this code. Since the value of $post_id should an integer limiting its value to that would have also prevented that as well. That SQL injection vulnerability is exploitable directly by anyone logged in to WordPress and it can also be exploited through the next security failure.

When making a request to duplicate a post or page the URL looks like this:

/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

What is missing from that is a nonce, which is a unique value used to prevent cross-site request forgery (CSRF). CSRF allows an attacker to cause someone that is allowed to take an action to take it when they are not intending to. In this case getting someone logged in to WordPress to click a link to a URL like that would cause a duplication to occur. That doesn’t really seem like a major issue here since the duplicate is saved as a draft. It could be used combined with the SQL injection vulnerability, though the usefulness of that is limited as well.

One of the things that we bring to the table that there probably isn’t another company comes close to with when it comes to vulnerabilities in WordPress, is a store house of knowledge from reviewing well over a thousand vulnerabilities. So when it came to this plugin we had previously looked at the details of a CSRF vulnerability in very similar plugin, Duplicate Post, which has 2+ million active installs. That led us to noticing the final issue with this plugin.

The plugin allows anyone logged in to WordPress to duplicate any post or page. For publicly viewable content that doesn’t really matter, but it could allow a lower level user without access to a password protected post to duplicate it and then view the contents of the post. That could be prevented by checking if a user is allowed to edit the post or page before doing the duplication.

We notified the developer of all but the last issue on October 4 through the contact form on their website. We then sent an email to the email address listed on the plugin’s page on wordpress.org that included all of the issues a week ago. We have yet to receive any response and a new version of the plugin has not been released.

Development Standards

The developer of the plugin, Webdesi9, presents their capabilities with WordPress plugins differently than the security of this plugin would seem to indicate.

They claim to “follow best quality standards”, which seems to not be the case:

Conferring you with fully functional plugins, our WordPress plugin development follow best quality standards. Get powerful and versatile WordPress plugins developed at Webdesi9.

They also claim to have “expert” WordPress plugin developers, which if true, doesn’t say good things about the handling of security in WordPress plugins in general:

Our experienced and expert set of WordPress Plugin developers provide power packed features and custom plug-ins to augment the performance and productivity of your website.

While the vulnerabilities in Duplicate Page have a limited impact, in another of the developer’s plugins the poor security was more serious. For about the first ten months that their plugin, WP File Manager existed, it would have allowed an attacker to view arbitrary files on a website and also allowed arbitrary files to be uploaded. Those are two of the top types of vulnerabilities in terms of exploit attempts (the vulnerabilities in Duplicate Page are unlikely to be exploited on the average website). When a security change was made that fixed those (but didn’t properly secure things) the developer didn’t change the version for two months, leading to probably 10s of thousands of websites to remain vulnerable. We contacted the developer shortly after the security fix was made to let them know about the incomplete fix and the lack of a version number bump, but we received no response. When the version number was changed you wouldn’t have known there even was security update based on the changelog:

  • fix some Bug in 1.6 – Minor Update
  • System Properties Menu – Added(New)

Making Sure the Plugins You are Using Are Secure

While there are a lot of suggestions out there on how to determine if plugins are secure, we can only think of a couple that might be useful. The first is to look at how the developer has handled any previously disclosed vulnerabilities, which could give you some indication of how they handle security of the plugin. Beyond that, the only way to directly check on the security of the plugin is to have a security review done.

For both of this developer’s plugins a good review should have caught most of the issues in them.

With our service you can suggest/vote for plugins to receive a security review from us, so that any issues like in these plugin can be found and fixed or if they don’t get fixed, you are aware that the developer isn’t properly handling security. You can also order a review of plugin separately from the service.

17 Oct

Security Advice Should Rely on Evidence Instead of Biased Assumptions

When it comes to the poor state of security, while a lot of the problems can be placed at the feet of the security industry, the public plays an important role as well. One of the big problems we see are people providing recommendations and advice that isn’t based on any evidence. That would be a problem if was coming from security professionals, who might at least have some experience to base their assumptions on, but from the layman they usually don’t have any basis and can lead to very bad advice.

When it comes to WordPress for example, what we have found incredible is that while there are enough recommendations for various security plugins that claimed that the plugin would protect your website being hacked that you could spend days (or maybe longer) reading them all, we only found one instance of someone other than us actually doing any testing to see if they could protect against real threats that they actually could and should be able to provide some protection against. The results of our testing and the other instance of that testing were not good. Most plugins have provided no protection what so ever and for the few plugins that provided any protection, the protection was usually easily bypassed.

Another area where we frequently see advice being made that clearly isn’t coming from people that are knowledgeable and isn’t be based on evidence, is how to choose a secure plugin to use. We have seen people suggesting making decision based on all sorts of things, including the popularity of the plugin, the rating of the plugin, and many others.

Recently we ran across another suggestion, this one coming from the maker of a WordPress plugin, to only use plugins with a monetization option:

So, going forward, we are only going to recommend and use plugins where it is clear to us what the upside is for the author.  This means that many good plugins will soon be taken off our recommendation list and replaced with freemium ones (even if they are slightly inferior).

This recommendation came about due to the recent situation with plugin Postman SMTP, which is assumed to have been removed from the Plugin Directory due to a reflected cross-site scripting (XSS) vulnerability we discovered and disclosed.

The given reason for this recommendation is as follows:

This plugin is 100% free with no monetization options.  In other words, the author does not have a financial interest in the plugin and, instead, works on it in his spare time.  Had there been a premium version of this plugin available or some other way that the plugin was monetized, we have no doubt that a fix would have been available shortly after the issue was discovered.  But, since its 100% free with no upside, the author has no real incentive to provide a fix if there are other projects or a job that takes precedence.

While they have “no doubt that a fix would have been available shortly after the issue was discovered” they didn’t present any evidence to back that up.

Considering that among other things, we are probably the most frequent discoverer of vulnerabilities in WordPress plugins these days, we are probably the best qualified to judge the veracity of the statement.

While we haven’t kept statistics as how the developers of completely free plugins deal with reports of vulnerabilities versus monetized plugins (it might be interesting do that), we have plenty of experience were monetized plugins haven’t fixed been fixed in a timely manner or at all.

As a recent example of a monetized plugin with a type of vulnerability that is likely to be exploited, we notified the developer of the plugin Product Reviews (also none as Ultimate Reviews and reviews) about a PHP object injection vulnerability in their plugin on July 24. There is a paid version of that plugin available. Nearly three months later the vulnerability still hasn’t been fixed. That is despite the plugin last being updated only three weeks ago. We have also notified that developer of multiple vulnerabilities in another of their plugins and none of those have been fixed either.

A couple of other plugins show one of the reasons that simply having a monetization option isn’t going to insure that a vulnerability will be fixed. With both the plugins Contact Form 7 – PayPal Add-on and Salon booking system the developers left comments on our posts claiming that the vulnerability didn’t exist (neither one had replied when we had originally contacted them before disclosing the vulnerability). The vulnerabilities do exist, the developers just didn’t understand them. That isn’t all that surprising since we often find that the WordPress focused security industry lacks even a basic understanding of security.

In this case the recommendation came from someone that seems to not really known what they are talking about. The recommender was claiming that with having “multiple-layers of firewalls” they could have been exploited:

We have used and recommended this plugin numerous times over the years.  This near-miss for us has caused us to re-evaluate what we use and recommend to our customers.  Had we not have multiple-layers of firewalls in place, this could have been a business reputation catastrophe if someone had exploited it on our site.

The reality is that the chances of being exploited by a reflected cross-site scripting (XSS) vulnerability are incredible low and they provided no evidence that “multiple-layers of firewalls” would have had any impact on being exploited.

Their recommendation to use monetized plugins isn’t exactly unbiased since they are the provider of a monetized plugin.

Their plugin actually introduces additional security risk on to websites, since it allows anyone to create a WordPress account and often there are vulnerabilities in plugins that are only exploitable to those logged in. It only took us seconds to find just such a vulnerability in their plugin and then we found another related one (which we have notified of them of and will disclose once they have a chance to fix them).

Making Sure You Are Using Secure Plugins

In their post they stated that:

However, this meant that anyone using the plugin (estimated at about 100,000 users) was exposed to this known vulnerability for at least 2 extra months.

That wasn’t true for our customers because they started get warned about the vulnerability at the time we disclosed it. So right there is a benefit of using our service. But if you are concerned about the security of a particular plugin instead of waiting for us or someone else to happen upon a vulnerability, if you are paying customer of our service you can suggest/vote for a plugin to receive a security review from us. You can also order a review of plugin separately from the service.

A security review is the only way you are really going to be able to determine if a plugin is secure or not.

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:

Sources

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" => "2.6.3.1 ",
		"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:

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

with

346
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 3.7.9.3 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 3.7.9.2 (in the file /includes/class_rm_dbmanager.php):

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

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

687
$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 3.7.9.3 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):