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“.
I’m the author of these posts. The purpose of the posts is to give site admins in higher ed a heads up about WordPress-related disclosures that have occurred in the last week. Those of us in higher ed are understaffed and under-resourced. We often don’t have the luxury of signing up for services like yours *even if we really, really want to*. I have subscriptions and alerts set up at every possible database and disclosure site and then comb through those each week trying to find recent disclosures that affect WordPress, again, all in an attempt to help other admins keep their sites safe. Many of them are unable to just “keep plugins up-to-date” due to either internal change management policies, lack of resources, or internal politics. Having something that shows a recent disclosure gives them the ability to push on getting that plugin updated.
I do not get paid to the write the posts or compile the lists, but do them in my free time out of a sense of duty to make the higher ed space more secure. I _believe_ in application security, and how *critically* important it is.
If you follow the link to the spreadsheets, you *are* credited in *every single instance* where the source of the discovery was your blog. As for the Wordfence htaccess entry, that was from expoit-db.com and my write up was based on the entry there. I’m sure my write up is similar to yours because we were both explaining the same thing. No where in any of the posts do I claim to be the discoverer of a vulnerability. In every post, each disclosure is sourced in the spreadsheets from where I initially learned of the disclosure.
If I made a mistake about your use php-grinder, I’ll be happy to correct the post I wrote. All you had to do is let me know of the mistake.
At the end of the day, if you truly believe in making WordPress, its ecosystem, and its community more secure, then we are on the same team. It would have been nice if you had reached out to me directly and shared your concerns with my posts, as I would be happy to make corrections, instead of me finding out through your blog. It’s not exactly hard to find me online.
Keeping plugins up to date is critical as you simply won’t know that a lot of vulnerabilities have been fixed, so your resources would seem be best focused on changing the situation in higher ed, instead of what you are doing now, because if that is the current situation, it is a big problem.
We really have hard time believing those in higher ed couldn’t afford our service at the current price, but we would happy to see about providing alternative pricing for higher ed that would work for them if they want to get in touch with us. No one has brought this up to us before. A year’s worth of the service is only a dollar more than tickets for WPCampus last year (we couldn’t find this year’s price), so clearly that kind of money is available.
With all that being said the issue wasn’t purchasing our service, it was properly crediting us when we are your source, which hasn’t been happening in plenty of instances, as was noted in the post. In one instance where we received partially credit in one of your posts, it led to a free trial for our service. So simply properly crediting us could lead to more customers for our services. The more customers that we have the more that we can do to improve the security of plugins for everyone, so properly crediting us would actually help those admins you mentioned.
The reason we publicly disclosed this because of just the kind of stuff in your comment, which is quite common in these types of situations.
Questioning if we “truly believe in making WordPress, its ecosystem, and its community more secure, then we are on the same team” is quite inappropriate, especially since you already know what we do. You credited us as the source for 45 percent of the entries (27 of 60 entries) in your spreadsheets from September, so you are clearly aware of the critical role we play when it comes to the security of WordPress plugins. Just this week we helped get plugins with 140,200+ active installs fixed. We also notified developers of plugins with another 500,000+ active installs of vulnerabilities of vulnerabilities that are in need of fixing in their plugins.
The rest of your comment walks around what we actually said. For example, we never claimed that you “claim to be the discoverer of a vulnerability”. The issue is that you are not citing your sources in your posts, which you are not.
As for the Wordfence info, here is the entirety of what is written on expoit-db.com:
So what you wrote is based on information that came from elsewhere. Everyone can compare what you wrote to what we wrote a week before, as well as looking at how our post is sourced to where we got the various information, while yours isn’t sourced.
You don’t address at all why you are providing inaccurate information on what version of vulnerabilities are impacted, which is both misleading the admins you are trying to help and the general public that would falsely believe the information that we, at this point, uniquely provide, can be gotten elsewhere.