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.)
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“.