When it comes to security surrounding WordPress unfortunately there are lots of irresponsible parties that, either because they don’t understand security or because they don’t care, are spreading false information. That makes it harder to deal with the real problems that exist and are not getting the attention they need. Take for instance Wordfence the maker of the most popular WordPress security plugin, that among other things makes up threats and spread false information about claimed vulnerabilities in WordPress plugins, while the public continues to be left in the dark when they are using plugins that have been removed from the wordpress.org Plugin Directory due to security issues (including ones that are being exploited on a wide scale).
Another example we just ran across is the website Plugin Problems, pluginproblems.info, which appears to mainly exist to advertise the web hosting company WPX Hosting. We ran across them as they signed up for our service in what looks to an attempt lift information we provide to our clients, for their own website. Beyond any impact on our business doing that would cause, that is problematic as they have already shown they will spread widely false information, which we don’t want to have any part in enabling, so we have canceled their free trial for our service. The spreading of widely false information we spotted involves their first post titled “LayerSlider: XSS & SQL Injection Vulnerability“.
In what seems like rather bad form they don’t even mention who disclosed the claimed vulnerability they are writing about or link to the discloser’s post on it, which can be found here.
The post on Plugin Problems doesn’t get past the first sentence without a couple of major falsehoods:
It has just come to light that the popular plugin, LayerSlider Responsive WordPress Slider Plugin, by kreatura, currently has a massive vulnerability.
Near the end of the post you would find that the claim the plugin currently has the claimed vulnerability isn’t true, as it states:
To patch up the security gap on your website, you must update your Layer Slider plugin to the latest version or at least to version 6.2.1.
So as long as you are keeping it up to date, then you would be protected if the vulnerability had existed. That mistake is minor in comparison to the claim that the plugin has a “massive vulnerability”, as in reality what is claimed to be the vulnerability by the original discloser is a type of vulnerability that at this time has almost no chance of being exploited on the average website.
A couple of paragraph’s down we think that anyone that deals much in the security of WordPress plugins would see something that indicates the person writing the post doesn’t understand the basics, which would be a good reason for the company behind this website not creating the website or writing that post:
In the Slider Settings screen, there’s an option to save any changes. When saving those changes however, the plugin does not validate the request with a nonce (a string generated by WordPress which acts as a token for each request and is used to identify the WP user which is making that request).
A nonce is used to make sure that a user intended to take an action; it isn’t used to identify what user is making a request. The use of a nonce prevents cross-site request forgery (CSRF). Nowhere in the post is CSRF mentioned, but in the original it takes center stage as the post is titled “Layer Slider 6.2.0 CSRF to XSS to SQLi with POC”.
Seeing as we don’t see any evidence of attempts to exploit CSRF vulnerabilities on the average website at this time this would make the vulnerability rather minor, something that even the original discloser doesn’t seems to be aware of as they claim the impact is:
8/10 . It is CSRF to stored XSS bug, but LayerSlider has more than 55.000 sales and God knows in how many WordPress themes it is bundled in. This puts it as a high impact vulnerability.
If this type of issue was really as concerning as they both claim that would be a very big problem as cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerabilities are rather common and based on some recent interaction with developers to try get them fix, something that plugin developers often don’t have a even a basic understanding of.
One of the things we uniquely provide when it comes to data on vulnerabilities in WordPress plugin is an estimation of the likelihood of exploitation, so if you use our service you can avoid being misled by the frequent overstated claims of the severity of vulnerabilities.
The next part of Plugin Problem post diverges from the original discloser as they state:
Therefore, when the request is not validated, the user does not have to be an administrator to save those settings.
Once again something that is bolder is not true, as if you look at the discloser’s proof of concept it states to test it you need to:
log in to a website with Admin privileges
If you were to read the rest of their details, it would sound like this is a “massive” vulnerability but based on the reality of rest of it there is little risk here:
With a simple POST request to ‘admin-ajax.php’, any SQL injection can be performed through Layer Slider’s vulnerability.
This weakness can allow hackers to see the current users on a website, or even create an administrator user for themselves and explore the site freely.
It Wasn’t One Time Thing
Plugin Problems post taking from one of our posts for our customers is equally bad. As with the previous example, the bolding in their post refers to something that isn’t’ true:
This vulnerability is particularly for version 6.18 of the plugin.
The vulnerability is not particular to one version, but impacted numerous versions. That is something that a customers of ours that was using plugin would know because one of the things we do that you won’t find elsewhere is an accurate listing of impacted versions of a plugin.
The rest of their post is full of things large and small that are either not true or don’t even make sense. On the low end, it claims the latest version of the plugin is 6.19, despite that not being true. When it comes to not making sense there is this:
In part of the plugin’s code, where the pages and their actions are defined, the classes are not sanitized.
Sanitisation of fields and classes in PHP means to validate and make sure that the code/input is properly formatted.
Someone that writes PHP code would probably be rather confused by a reference sanitizing PHP classes since those are a structural element of code and not something that sanitization would be relevant to. What looks to have happened is the writer is in some way referring to the fact that reflected cross-site scripting (XSS) vulnerability in the plugin involves something output in class attribute of an HTML element and mix that in to something that doesn’t make sense. The need for sanitization would be the same if was occurring anywhere else, so being output in a class attribute wouldn’t be a significant thing.
More False Information from WPX Hosting
A quick check of the website of the web hosting behind the Plugin Problems website showed that their spreading of bad information on WordPress security isn’t limited to that website.
For example, on the page What Security Plugins does WPX Hosting Recommend? they write:
WordPress is the world’s most popular blogging platform; due to this popularity, hackers have taken an interest in taking advantage of poorly secured WordPress websites.
Using a security plugin on your website is highly recommended, as they will keep your website secure from known vulnerabilities.
There are many security plugins out there, however not all of them do a good job. We have tested out many of the released security plugins and have found the following most useful in securing websites:
In reality we have done testing of security plugins and found that they provide little to no protection against known vulnerabilities in other plugins. In the most recent test of a vulnerability that looks to have been being exploited on a wide scale, none of the plugins provided protection in the test. For two of three plugins they recommend, iThemes Security and Sucuri Security, they have provided no protection in our testing and neither of them even look as if they are designed to provide protection, so the claim by WPX Hosting there is very wrong.
If you are looking for actual protection installing the companion plugin for our service will alert you to vulnerabilities in plugins once we start to see them being targeted by hackers. Signing up for our service will get you access to expanded vulnerability data, support if you are dealing with a vulnerable plugin that hasn’t been fixed, and the ability to participate in deciding what plugins will receive security reviews from us.